<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-02-26 20:45 GMT+01:00 Tuncer Ayaz <span dir="ltr"><<a href="mailto:tuncer.ayaz@gmail.com" target="_blank">tuncer.ayaz@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">On Wed, Feb 26, 2014 at 8:20 PM, Andreas Stenius wrote:<br>
>> [...]<br>
</div>>> 2014-02-24 21:17 GMT+01:00 Tuncer Ayaz:<br>
<div class="">>><br>
>>> You can consider it a rebar bug, if you have to manually list parse<br>
>>> transforms in erl_first_files. If that's the case, give the (hopefully<br>
>>> soon to be merged) <a href="https://github.com/rebar/rebar/pull/129" target="_blank">https://github.com/rebar/rebar/pull/129</a> a try.<br>
>><br>
>><br>
><br>
> The issue seems a bit deeper than that. The thing is, that merl has<br>
> some rather unusual compile rules for compiling the parse transform,<br>
> in that it compiles it twice, and for the second pass, it applies<br>
> itself during compile.<br>
><br>
> So, is there any way to tell rebar to use a projects make file<br>
> rather than simply compiling erl files and "hoping" for the best;<br>
> especially when there is no rebar.config for the project. (@tuncer?)<br>
<br>
</div>As long as the project follows otp project structure conventions<br>
and doesn't require extra configuration (defaults are okay), you don't<br>
need rebar.config.<br></blockquote><div><br></div><div>Well, yes, but in this case, there was some special treatments needed..</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><br>
> I was considering that it would be possible to achieve the same<br>
> build using a rebar config file using hooks and stuff, but then I<br>
> suppose it would need to live in the merl repo.. ? feels like that<br>
> would defeat the purpose a bit, if I need to tweak the dependency<br>
> project to make it work with rebar.. or I'm not familiar enough with<br>
> rebar, which is more than likely ;)<br>
><br>
> Either that, or I could add merl as a git subproject, and hook it up<br>
> that way, integrating the merl build into the erlydtl one, so that<br>
> the merl beam files and includes would be available from erlydtl's<br>
> path.. but that's a rather kludgy way of doing things.. hmm.<br>
<br>
</div>Have you tried {pre_hooks, [{'compile', "make -C deps/merl"}]}?<br>
I didn't test that, but I'd expect something like that to work.<br>
</blockquote></div><br></div><div class="gmail_extra">That, in combination with listing the merl dep as `raw` seems to have worked (looked good in my very limited envrionment, awaiting responses [1]).</div><div class="gmail_extra">
Thanks for the tip :) (although, I used "make -C $REBAR_DEPS_DIR/merl all", as the deps dir could be anywhere, really..)</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://github.com/erlydtl/erlydtl/issues/123#issuecomment-36169576">https://github.com/erlydtl/erlydtl/issues/123#issuecomment-36169576</a></div>
</div>