One approach I tried was to create an application which doesn't do anything, but contains the record definitions common to multiple projects. Then I used rebar to include it as a dependency. When including the hrl files, I use the include_lib
syntax. That syntax allows you to include hrl files from another application.
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
example which could appear in either some_src.erl or other_src.erl:
-include_lib("common_hrl_app/include/common_records.hrl").
I like this approach because:
- It plays nicely with the rebar dependency system
- It allows me to track the hrls in one place in version control
- I can version this application, which allows me to pull specific versions if I want a new application to be compatible with another using the same records.
Answering questions from the comments:
I have a skeleton app file in the ebin directory which specifies the name and version of the application so rebar can verify the version. Here's an example
{application,common_hrl_app,
[{description,[]},
{vsn,"1"},
{registered,[]},
{applications,[kernel,stdlib]},
{env,[]},
{modules,[]}]}.
With rebar, you have the top level application, which can have multiple applications as dependencies. When rebar fetches these dependencies, it places them in the deps directory. If any of those applications has their own dependencies, those are also fetched to the deps directory, and so on. There isn't an infinitely nested hierarchy of deps directories.