awkward project dir structure and proper release handling
watson.timothy at gmail.com
Sat Feb 18 19:33:17 EST 2012
Use different configs for different things. You can have rebar.config
and release.config for example, and run the latter with `rebar -C
release.config compile generate ct`
Also, from the sounds of things, if you want app1 to be available as a
standalone component, you should package it separately in a different
git repository as a stand-alone OTP application (not release). Then
you may do the same with app2 or app3 and reference them as
dependencies of app1 if required. Once you're finished, you can create
two (or more) different kinds of release.config with different names
in the main release repository, or use different release repositories
(or branches if you're so inclined, but I'd avoid that personally) to
glue together these dependant applications in different ways.
If in doubt, look at the way it's done in the main riak repository.
This is essentially a shell for building a release out of multiple
external applications which are pulled in as dependencies. Personally,
I tend to avoid apps/sub_dirs as it makes having multiple packaging
options much harder.
Those are my two pennies.
On 14 February 2012 16:05, Martynas Pumputis <martynasp at gmail.com> wrote:
> Not only tests, but also compile it, i.e. we want to have "stand alone" app
> (having a list of all app1 deps in app1/rebar.config instead of in top level
> On Tue, Feb 14, 2012 at 3:35 PM, Matthew Campbell
> <matthew.campbell at asolutions.com> wrote:
>> On Feb 14, 2012, at 7:54, Martynas Pumputis <martynasp at gmail.com> wrote:
>> > But whats about running each app[1..3] separately?
>> By this I think you mean running eunit tests for separate apps separately,
>> You can choose one or more apps from top level if you do it like so:
>> ./rebar eunit skip_deps=true apps=app1
>> rebar mailing list
>> rebar at lists.basho.com
> rebar mailing list
> rebar at lists.basho.com
More information about the rebar