using file:script() if possible

Tim Watson watson.timothy at gmail.com
Tue Feb 14 14:17:26 EST 2012


On 14 February 2012 16:51, Tuncer Ayaz <tuncer.ayaz at gmail.com> wrote:

> >
> > 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).
>

Ulf - if that plugin isn't project specific (i.e., will work for any
rebar.config setup) it might be worth releasing as a general purpose tool
and/or looking at whether rebar could/should do this all the time.


>
> 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.
>
>

@tuncer - that doesn't work. Rebar doesn't execute 'generate' if it can't
find reltool.config in the appropriate directory - which is most annoying!
- so the plugin never gets a chance to run anyway. Take a lookg at
https://github.com/hyperthunk/alien_deps_example/blob/master/pre_release_plugin.erl#L24for
details. You *could* have the generation code run on post_compile I
suppose, but that doesn't feel very intuitive and I'm not sure what the
right solution to this problem is.

Nonetheless, I agree that having a plugin generate the reltool.config
(using rebar_templater) is a good approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/rebar_lists.basho.com/attachments/20120214/d03fe7ad/attachment.html>


More information about the rebar mailing list