[erlang-questions] Library application and it's dependencies

Tuncer Ayaz <>
Wed Feb 26 20:45:29 CET 2014

On Wed, Feb 26, 2014 at 8:20 PM, Andreas Stenius wrote:
>> [...]
>> 2014-02-24 21:17 GMT+01:00 Tuncer Ayaz:
>>> You can consider it a rebar bug, if you have to manually list parse
>>> transforms in erl_first_files. If that's the case, give the (hopefully
>>> soon to be merged) https://github.com/rebar/rebar/pull/129 a try.
> The issue seems a bit deeper than that. The thing is, that merl has
> some rather unusual compile rules for compiling the parse transform,
> in that it compiles it twice, and for the second pass, it applies
> itself during compile.
> So, is there any way to tell rebar to use a projects make file
> rather than simply compiling erl files and "hoping" for the best;
> especially when there is no rebar.config for the project. (@tuncer?)

As long as the project follows otp project structure conventions
and doesn't require extra configuration (defaults are okay), you don't
need rebar.config.

> I was considering that it would be possible to achieve the same
> build using a rebar config file using hooks and stuff, but then I
> suppose it would need to live in the merl repo.. ? feels like that
> would defeat the purpose a bit, if I need to tweak the dependency
> project to make it work with rebar.. or I'm not familiar enough with
> rebar, which is more than likely ;)
> Either that, or I could add merl as a git subproject, and hook it up
> that way, integrating the merl build into the erlydtl one, so that
> the merl beam files and includes would be available from erlydtl's
> path.. but that's a rather kludgy way of doing things.. hmm.

Have you tried {pre_hooks, [{'compile', "make -C deps/merl"}]}?
I didn't test that, but I'd expect something like that to work.

More information about the erlang-questions mailing list