FEEDBACK REQUEST: Configuration Inheritance
watson.timothy at gmail.com
Wed Mar 21 07:37:42 EDT 2012
Sorry I've been so long in responding to this, but it has drawn to my attention that I'm using a forked version of rebar in almost all my projects and various aspects do not build correctly without them. I had to do some serious git voodoo to wire this together, but here are my various projects building: https://gist.github.com/2141500 and another one at https://gist.github.com/2146342.
On 12 Mar 2012, at 14:34, David Smith wrote:
> Hi all,
> Rebar currently uses a scheme for inheriting config values across the
> directory tree. Consider the following case:
> When processing app1/rebar.config, Rebar will inherit any missing
> config values from the top-level rebar.config. This is convenient when
> you have a bunch of apps within a single repo and want to ensure they
> all use same config options. Now consider the following:
> In this situation, deps/dep1 was pulled in dynamically and should NOT
> inherit config options, since arguably the dependency should be
> independent of the projects using it. We've had several people have
> issues with this recently.
> So, the question is -- how useful is config inheritance? Should we
> keep it or does it cause more problems than it solves?
> To help us answer this, we'd like you to give a custom version of
> rebar a run on your repos and mail the output to any of tuncer, myself
> or the list.
> You can try this custom version of rebar by doing the following:
> git clone git://github.com/basho/rebar
> git checkout -b ta-conftest
> cp rebar <your project>
> That custom rebar will then output lines starting with "CONFTEST:" to
> indicate when configuration inheritance is used.
> Dave Smith
> VP, Engineering
> Basho Technologies, Inc.
> dizzyd at basho.com
> rebar mailing list
> rebar at lists.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rebar