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

[Andreas Stenius]

2014-02-26 20:45 GMT+01:00 Tuncer Ayaz <tuncer.ayaz@REDACTED>:

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

Well, yes, but in this case, there was some special treatments needed..


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

That, in combination with listing the merl dep as `raw` seems to have
worked (looked good in my very limited envrionment, awaiting responses [1]).
Thanks for the tip :) (although, I used "make -C $REBAR_DEPS_DIR/merl all",
as the deps dir could be anywhere, really..)

[1] https://github.com/erlydtl/erlydtl/issues/123#issuecomment-36169576
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140226/1bb4ab7c/attachment.htm>