Erlang/OTP 应用程序的头文件位置
Header files location for an Erlang/OTP application
我应该将 Erlang/OTP 应用程序的 .hrl 头文件放在 /src 或 /include 目录中吗？
发件人：http://erlang.org/doc/design_principles/applications.html
- src - Required. Contains the Erlang source code, the source of the .app file and internal include files used by the application itself. [...]
- include - Optional. Used for public include files that must be reachable from other applications.
这也解释为：http://erlang.org/pipermail/erlang-questions/2009-July/045516.html
Use Case 1:
Your project has -defined constants, parse transforms, etc. which are required for others to use your code. Examples include qlc or webmachine.
Solution: Put your .hrl files in /include. As long as your project is on the code path then clients of your code can use -include_lib() to load the .hrl files.
Use Case 2: You've centralised common constants, etc. in a .hrl file. These constants are intended to be used internally by your project code. This means at no time will any client need access to them.
Solution: Put your .hrl files in /src. Your code can use -include() to pull in the .hrl files.
Keep in mind that both include directives are compile-time constructs. You can put all of your header files in /src, compile your code using -include(), and then selectively "export" the header files you want to publish by copying them into /include. I do this a lot since it makes my compile process easier -- no code path to futz with -- and it makes my client code cleaner -- they can use -include_lib() to find my public header files.
--Kevin
我应该将 Erlang/OTP 应用程序的 .hrl 头文件放在 /src 或 /include 目录中吗？
发件人：http://erlang.org/doc/design_principles/applications.html
- src - Required. Contains the Erlang source code, the source of the .app file and internal include files used by the application itself. [...]
- include - Optional. Used for public include files that must be reachable from other applications.
这也解释为：http://erlang.org/pipermail/erlang-questions/2009-July/045516.html
Use Case 1: Your project has
-defined constants, parse transforms, etc. which are required for others to use your code. Examples includeqlcorwebmachine.Solution: Put your
.hrlfiles in/include. As long as your project is on the code path then clients of your code can use-include_lib()to load the.hrlfiles.
Use Case 2: You've centralised common constants, etc. in a
.hrlfile. These constants are intended to be used internally by your project code. This means at no time will any client need access to them.Solution: Put your
.hrlfiles in/src. Your code can use-include()to pull in the.hrlfiles.
Keep in mind that both include directives are compile-time constructs. You can put all of your header files in
/src, compile your code using-include(), and then selectively "export" the header files you want to publish by copying them into/include. I do this a lot since it makes my compile process easier -- no code path to futz with -- and it makes my client code cleaner -- they can use-include_lib()to find my public header files.--Kevin