using file:script() if possible

Tuncer Ayaz tuncer.ayaz at gmail.com
Tue Feb 14 11:51:01 EST 2012


On Tue, Feb 14, 2012 at 2:52 PM, Ulf Wiger <ulf at feuerlabs.com> wrote:
>
> Hi Tuncer,
>
> It definitely sounds useful, although I don't have a concrete case
> for it myself and haven't thought through the implications.
>
> In my own current build project, I have a separate rebar.config
> under rel/, and a rebar plugin that does some infilling of a
> retool.config.src. For one thing, it takes a list of application
> names from the rebar.config, and inserts the needed boilerplate in
> the {sys, …} tuple. It also fixes the rel_dirs, in case you want to
> find applications using ERL_LIBS and REBAR_DEPS (as described
> earlier).

Wouldn't it be cleaner to use a pre_generate plugin and use that to
generate reltool.config? That would allow you to have a single
rebar.config.

> In a way, I feel a bit more comfortable having a plugin work from
> X.src files and transform them into appropriate targets, than having
> internal options magically modified by plugins, but that's just from
> the gut. I may well be wrong on that.

For that specific case that may be ok, but implementing support to
mutate configuration is something which can support all kinds special
use cases (overriding options, removing options, adding options, ...).

Is generating a temporary rebar.config and storing it on disk
preferable to loading the generic config and mutating it at runtime?

> On 14 Feb 2012, at 10:15, Tuncer Ayaz wrote:
>
>> On Fri, Feb 10, 2012 at 3:30 PM, Ulf Wiger wrote:
>>>
>>> I made a little rebar hack just now that perhaps might work for some of the
>>> trickier path issues, or for local customization.
>>>
>>> https://github.com/uwiger/rebar/blob/uw-config-script/src/rebar_config.erl#L135
>>>
>>> The idea is to check if there is a config file in the form of a
>>> file:script/2 file, here identified with the suffix .script.
>>>
>>> In other words, when we would consult rebar.config, we check if there is a
>>> rebar.config.script, and then read it instead, using
>>>
>>> file:script(Script, [{'SCRIPT', Script}])
>>>
>>> I know one can use the -config flag and point to a different rebar.config,
>>> but if rebar is wrapped inside a make script, perhaps with fairly
>>> complicated targets, this may prove unwieldy.
>>>
>>> This way, I can throw in a wrapper, which amends the rebar.config in some
>>> way, still being able to use the make script and not having to mess up the
>>> git merges by hacking a version-controlled file.
>>
>> Thanks Ulf, obvious and good concept.
>> We've had discussions about different ways to modify configuration at
>> runtime. Your concept solves it for the startup phase, but we were
>> also discussing whether it'd be a good idea to let rebar plugins
>> return a modified rebar_config:config() variable.
>>
>> Thoughts? Dizzy?



More information about the rebar mailing list