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

[Siri Hansen]

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130415/3d348219/attachment.htm>