[erlang-questions] reltool: sys-level {mod_cond, derived}

[Tuncer Ayaz]

On Mon, Apr 15, 2013 at 11:49 AM, Siri Hansen wrote:
> I think this only reflects the application dependencies as they
> actually look
>
> sasl uses tools
> tools uses webtool (cover) and inets
> webtool uses observer
> inets uses mnesia, runtime_tools, ssl,
> observer uses gs, wx, et
> ssl uses crypto and public_key
> ...
>
> Adding {mod_cond,derived} is the way to limit the way reltool
> calculates the application dependencies.

AFAIU, reltool has the relevant information at runtime and could warn
about missing deps or derive the deps even when {mod_cond,derived} is
set.

Isn't that the most reasonable behavior?

Or is there a distinction between hard and soft mod deps?

> Regards
> /siri
>
> 2013/4/6 Tuncer Ayaz <tuncer.ayaz@REDACTED>
>>
>> As discussed previously[1] it was decided to make the default
>> rebar reltool.config template safer to use by removing[2] the
>> non-default sys-level mod_cond.
>>
>> While this doesn't produce releases with potentially missing
>> modules, that one-line patch also pulls in many seemingly unused
>> applications resulting in a release that's at least twice as big:
>>
>> With sys-level {mod_cond, derived} (aka non-default settings):
>> $ ls -1 rel/exemplar/lib
>> compiler-4.9.1
>> crypto-2.3
>> erts-5.10.1
>> exemplar
>> hipe-3.10.1
>> kernel-2.16.1
>> sasl-2.3.1
>> stdlib-1.19.1
>> tools-2.6.10
>>
>> Without sys-level {mod_cond, derived} (aka default settings):
>> $ g diff
>> diff --git a/rel/reltool.config b/rel/reltool.config
>> index 2dd47be..e65c53c 100644
>> --- a/rel/reltool.config
>> +++ b/rel/reltool.config
>> @@ -19,7 +19,6 @@
>>         {boot_rel, "exemplar"},
>>         {profile, embedded},
>>         {incl_cond, derived},
>> -       {mod_cond, derived},
>>         {excl_archive_filters, [".*"]}, %% Do not archive built libs
>>         {excl_sys_filters, ["^bin/.*", "^erts.*/bin/(dialyzer|typer)",
>>                             "^erts.*/(doc|info|include|lib|man|src)"]},
>>
>> $ ls -1 rel/exemplar/lib
>> asn1-2.0.1
>> compiler-4.9.1
>> crypto-2.3
>> edoc-0.7.12
>> erts-5.10.1
>> et-1.4.4.3
>> exemplar
>> gs-1.5.15.2
>> hipe-3.10.1
>> inets-5.9.4
>> kernel-2.16.1
>> mnesia-4.8
>> observer-1.3
>> public_key-0.18
>> runtime_tools-1.8.10
>> sasl-2.3.1
>> ssl-5.2.1
>> stdlib-1.19.1
>> syntax_tools-1.6.11
>> tools-2.6.10
>> webtool-0.8.9.2
>> wx-1.0
>> xmerl-1.3.3
>>
>> To reproduce, follow the steps found in
>> https://github.com/rebar/rebar/wiki/Release-handling
>> and make sure to delete the sys-level mod_cond.
>>
>> If you want to keep the sys-level {mod_cond, derived} and use the
>> nodetool escript, remember to add the following line:
>> {app, compiler, [{mod_cond, app}]},
>> Otherwise reltool might not include[3] some compiler modules which are
>> used due to the `-mode(compile)` directive. As I don't think the
>> nodetool escript has anything to gain by being compiled, I've posted a
>> patch to delete[4] the directive.
>>
>> So, the question is, is this expected reltool behaviour? If so, is
>> this really desired or not possibly including much more than is
>> actually used. Shouldn't the sys-level {incl_cond, derived} make
>> sure only used applications are included (regardless of mod_cond)?
>>
>> [1] http://erlang.org/pipermail/erlang-questions/2012-December/071135.html
>> [2] https://github.com/rebar/rebar/pull/43
>> [3] https://github.com/rebar/rebar/issues/64#issuecomment-15998750
>> [4] https://github.com/rebar/rebar/pull/80