Multi OTP app project

Garrett Smith g at
Thu Jun 23 17:52:24 EDT 2011

Thanks OJ.

I'm wondering though if my project structure is a by-product of the
general app dependency problem in Erlang. I tend to grab the source
from required projects and throw them into "lib" (or "apps" in your
case), which works pretty well, but obviously presents a maintenance

Is there a pattern for using the "deps" feature in rebar (I admittedly
don't fully understand how that works) with symlinks to "peer"
projects? E.g. I could hard-wire an app to look for its dependencies
in the app's parent dir. Rather than have rebar auto-resolve
dependencies using git (or whatever it does), it'd be up to the
developer to install the required apps as peers.

E.g. one might use a top-level "source" dir for all projects, grab
whatever was needed and, assuming the OTP apps used the expected
directory structure, the dependencies in my app would resolve


On Thu, Jun 23, 2011 at 4:40 PM, OJ Reeves <oj at> wrote:
> Garrett,
> I do something similar with my projects (though they live in an "apps"
> folder instead of "lib").
> You can tell rebar to build your applications by adding the following to
> rebar.config (in the root folder):
> % specify the subfolders for each project you want to build
> {sub_dirs, ["lib/app_1", "lib/app_2", ... , "lib/app_n"]}.
> % tell rebar to include "lib" in your include paths
> {erl_opts, [{i, "lib"}]}.
> I think that each individual application under "lib" would also need to be
> buildable via rebar as well, but I think someone else might be better
> positioned to confirm that myself (I've always had it that way in my
> projects). You may also have dependencies for each of those projects, which
> would result in a "deps" folder being created in the root folder. If that is
> the case, I'd suggset adding another include folder ({i, "deps"}) if your
> applications include stuff from their dependencies.
> As far as releases with rebar are concerned, may I suggest you take a look
> at @metabrew's blog post on the topic. I found it quite useful.
> All the best!
> OJ
> PS. Love your email address :)
> On 24 June 2011 07:31, Garrett Smith <g at> wrote:
>> I'm evaluating rebar to replace a makefile based build system.
>> I typically work with projects that have this structure:
>> ./lib/app_1/src
>> ./lib/app_1/ebin
>> ./lib/app_1/priv
>> ./lib/app_1/include
>> ./lib/app_2/src
>> ./lib/app_2/ebin
>> ./lib/app_2/priv
>> ./lib/app_2/include
>> ./rel/R14B/some_release_1.rel
>> ./rel/R14B/some_release_2.rel
>> There's an assumption that every OTP app under "lib" is available as
>> if it were installed -- e.g. include_lib("app_1/include/yo.hrl")
>> works.
>> I do this by setting ERL_LIBS=lib for running and compiling.
>> For the most part, this project structure resembles OTP itself.
>> Can someone help me understand how rebar could be used to manage this
>> type of project?
>> Garrett
>> _______________________________________________
>> rebar mailing list
>> rebar at
> --
> OJ Reeves

More information about the rebar mailing list