<div dir="ltr">Do you mean that reltool knows about the -mode(compile) directive and should be able to figure out the dependencies towards compiler?<div>/siri</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/10/21 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Apr 15, 2013 at 11:49 AM, Siri Hansen wrote:<br>
> I think this only reflects the application dependencies as they<br>
> actually look<br>
><br>
> sasl uses tools<br>
> tools uses webtool (cover) and inets<br>
> webtool uses observer<br>
> inets uses mnesia, runtime_tools, ssl,<br>
> observer uses gs, wx, et<br>
> ssl uses crypto and public_key<br>
> ...<br>
><br>
> Adding {mod_cond,derived} is the way to limit the way reltool<br>
> calculates the application dependencies.<br>
<br>
</div>AFAIU, reltool has the relevant information at runtime and could warn<br>
about missing deps or derive the deps even when {mod_cond,derived} is<br>
set.<br>
<br>
Isn't that the most reasonable behavior?<br>
<br>
Or is there a distinction between hard and soft mod deps?<br>
<div class="HOEnZb"><div class="h5"><br>
> Regards<br>
> /siri<br>
><br>
> 2013/4/6 Tuncer Ayaz <<a href="mailto:tuncer.ayaz@gmail.com">tuncer.ayaz@gmail.com</a>><br>
>><br>
>> As discussed previously[1] it was decided to make the default<br>
>> rebar reltool.config template safer to use by removing[2] the<br>
>> non-default sys-level mod_cond.<br>
>><br>
>> While this doesn't produce releases with potentially missing<br>
>> modules, that one-line patch also pulls in many seemingly unused<br>
>> applications resulting in a release that's at least twice as big:<br>
>><br>
>> With sys-level {mod_cond, derived} (aka non-default settings):<br>
>> $ ls -1 rel/exemplar/lib<br>
>> compiler-4.9.1<br>
>> crypto-2.3<br>
>> erts-5.10.1<br>
>> exemplar<br>
>> hipe-3.10.1<br>
>> kernel-2.16.1<br>
>> sasl-2.3.1<br>
>> stdlib-1.19.1<br>
>> tools-2.6.10<br>
>><br>
>> Without sys-level {mod_cond, derived} (aka default settings):<br>
>> $ g diff<br>
>> diff --git a/rel/reltool.config b/rel/reltool.config<br>
>> index 2dd47be..e65c53c 100644<br>
>> --- a/rel/reltool.config<br>
>> +++ b/rel/reltool.config<br>
>> @@ -19,7 +19,6 @@<br>
>>         {boot_rel, "exemplar"},<br>
>>         {profile, embedded},<br>
>>         {incl_cond, derived},<br>
>> -       {mod_cond, derived},<br>
>>         {excl_archive_filters, [".*"]}, %% Do not archive built libs<br>
>>         {excl_sys_filters, ["^bin/.*", "^erts.*/bin/(dialyzer|typer)",<br>
>>                             "^erts.*/(doc|info|include|lib|man|src)"]},<br>
>><br>
>> $ ls -1 rel/exemplar/lib<br>
>> asn1-2.0.1<br>
>> compiler-4.9.1<br>
>> crypto-2.3<br>
>> edoc-0.7.12<br>
>> erts-5.10.1<br>
>> et-1.4.4.3<br>
>> exemplar<br>
>> gs-1.5.15.2<br>
>> hipe-3.10.1<br>
>> inets-5.9.4<br>
>> kernel-2.16.1<br>
>> mnesia-4.8<br>
>> observer-1.3<br>
>> public_key-0.18<br>
>> runtime_tools-1.8.10<br>
>> sasl-2.3.1<br>
>> ssl-5.2.1<br>
>> stdlib-1.19.1<br>
>> syntax_tools-1.6.11<br>
>> tools-2.6.10<br>
>> webtool-0.8.9.2<br>
>> wx-1.0<br>
>> xmerl-1.3.3<br>
>><br>
>> To reproduce, follow the steps found in<br>
>> <a href="https://github.com/rebar/rebar/wiki/Release-handling" target="_blank">https://github.com/rebar/rebar/wiki/Release-handling</a><br>
>> and make sure to delete the sys-level mod_cond.<br>
>><br>
>> If you want to keep the sys-level {mod_cond, derived} and use the<br>
>> nodetool escript, remember to add the following line:<br>
>> {app, compiler, [{mod_cond, app}]},<br>
>> Otherwise reltool might not include[3] some compiler modules which are<br>
>> used due to the `-mode(compile)` directive. As I don't think the<br>
>> nodetool escript has anything to gain by being compiled, I've posted a<br>
>> patch to delete[4] the directive.<br>
>><br>
>> So, the question is, is this expected reltool behaviour? If so, is<br>
>> this really desired or not possibly including much more than is<br>
>> actually used. Shouldn't the sys-level {incl_cond, derived} make<br>
>> sure only used applications are included (regardless of mod_cond)?<br>
>><br>
>> [1] <a href="http://erlang.org/pipermail/erlang-questions/2012-December/071135.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2012-December/071135.html</a><br>
>> [2] <a href="https://github.com/rebar/rebar/pull/43" target="_blank">https://github.com/rebar/rebar/pull/43</a><br>
>> [3] <a href="https://github.com/rebar/rebar/issues/64#issuecomment-15998750" target="_blank">https://github.com/rebar/rebar/issues/64#issuecomment-15998750</a><br>
>> [4] <a href="https://github.com/rebar/rebar/pull/80" target="_blank">https://github.com/rebar/rebar/pull/80</a><br>
</div></div></blockquote></div><br></div>