一种方法我试过是创建一个应用程序,它不会做任何事情,但包含常见的记录定义到多个项目。然后我用钢筋把它作为一个依赖项。当包含hrl文件时,我使用include_lib
语法。该语法允许您从其他应用程序中包含hrl文件。这可能出现在任何some_src.erl或other_src.erl
app
ebin
include
priv
src
some_src.erl
deps
common_hrl_app
include
common_records.hrl
src
ebin
other_dep_app
src
other_src.erl
.
.
.
include_lib
例如:
-include_lib("common_hrl_app/include/common_records.hrl").
我喜欢这种做法,因为:
- 它与螺纹钢依赖系统
起到很好
- 它允许我跟踪版本控制中的一个地方的hrls
- 我可以编写这个应用程序的版本,如果我想让一个新的应用程序与另一个使用相同记录的应用程序兼容,我可以使用这个应用程序。
从注释中回答问题:
我在指定的应用程序的名称和版本,因此螺纹钢可以验证版本的EBIN目录的骨架应用程序文件。这里有一个例子
{application,common_hrl_app,
[{description,[]},
{vsn,"1"},
{registered,[]},
{applications,[kernel,stdlib]},
{env,[]},
{modules,[]}]}.
随着螺纹钢,你有顶级的应用程序,它可以有多个应用程序的依赖关系。当rebar提取这些依赖关系时,它将它们放在deps目录中。如果这些应用程序中的任何一个具有它们自己的依赖关系,那么这些应用程序也会被提取到deps目录,等等。没有无限嵌套的deps目录层次结构。
这看起来很酷的解决方案。但是我对一些事情还不清楚,可能是因为我仍然对Rebar有些不稳定:1)common_hrl_app中的include目录是空的吗? 2)Deps子树是否会进入我的树中的其他应用程序? –
对答案增加了一些说明。 – kjw0188