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

[Siri Hansen]

Do you mean that reltool knows about the -mode(compile) directive and
should be able to figure out the dependencies towards compiler?
/siri


2013/10/21 Tuncer Ayaz <tuncer.ayaz@REDACTED>

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