Multi OTP app project

[OJ Reeves]

Hi Garrett,

Quick Q: why would you want your devs to pull the dependencies together
manually? Would it not be better to automate that?

In short: yes there is a pattern. Rebar's dependency management stuff is
pretty good, and I use it for many of my projects. It sounds to me like this
is exactly what you want, rather than having to pull the dependencies
together manually.

A great example of a top-level project being used to just pull dependencies
together is Riak <https://github.com/basho/riak>. Check out the rebar.config
<https://github.com/basho/riak/blob/master/rebar.config>and you'll see the
dependencies (some of which have their own dependencies too). Rebar pulls
them all together for you and drops them in the "deps" folder. As mentioned
in the previous email, you could add "deps" as an include folder, and you're
done.

It should be that simple (I hope!).

Apologies if I've missed something.

Cheers
OJ


On 24 June 2011 07:52, Garrett Smith <g at rre.tt> wrote:

> 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
> problem.
>
> 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
> properly.
>
> Garrett
>
> On Thu, Jun 23, 2011 at 4:40 PM, OJ Reeves <oj at buffered.io> 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.
> >
> > HTH
> > All the best!
> >
> > OJ
> >
> > PS. Love your email address :)
> >
> >
> > On 24 June 2011 07:31, Garrett Smith <g at rre.tt> 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 lists.basho.com
> >> http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com
> >
> >
> >
> > --
> >
> > OJ Reeves
> > http://buffered.io/
> >
>



-- 

OJ Reeves
http://buffered.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/rebar_lists.basho.com/attachments/20110624/b734c93a/attachment.html>