[erlang-questions] Running rebar generated release failing with Kernel pid terminated"
Loïc Hoguin
essen@REDACTED
Thu Dec 13 13:54:31 CET 2012
On 12/13/2012 01:42 PM, Tuncer Ayaz wrote:
> On Thu, Dec 13, 2012 at 1:28 PM, Loic Hoguin wrote:
>> On 12/13/2012 01:14 PM, Tuncer Ayaz wrote:
>>>
>>> On Thu, Dec 13, 2012 at 12:55 PM, Loic Hoguin wrote:
>>>>
>>>> The problem is probably that rebar doesn't use the default reltool
>>>> mod_cond value. So not all modules are included. Try changing it
>>>> to this:
>>>>
>>>> {mod_cond, all}
>>>
>>>
>>> For certain incorrect/incomplete app resource files you may have to
>>> use such a work around. Normally the right solution is to fix the
>>> app resource files.
>>
>>
>> Why change the default reltool value in the first place, though? I
>> don't get it. Also how would reltool know I need certain modules if
>> they're only used dynamically?
>
> The default reltool spec template you get when using 'rebar create' is
> configured to create a release that contains only what's required. I
> don't think reltool can or should know modules you load from
> unreferenced applications at runtime. If it's always the same module
> from the same application, you should specify the application in your
> app's app resource file. If this can't be done for some reason, just
> change the reltool spec accordingly. Unsurprisingly the default
> template won't work for every project and it's not supposed to.
Sure but you're contradicting people's expectations. If you could use
rebar's releases without having to know reltool this wouldn't be a
problem, but the reltool documentation here
http://www.erlang.org/doc/man/reltool.html says:
mod_cond
This parameter controls the module inclusion policy. It defaults to
all which means that if an application is included (either explicitly
or implicitly) all modules in that application will be included.
Not setting this to all by default is not only against the existing
documentation, but also has the problematic side effect that following
this guide https://github.com/rebar/rebar/wiki/Release-handling will
most likely *not* create a working release. It used to, but I suppose
the default was changed in recent months, which means that a few extra
steps and checks are needed.
Also with dynamically used modules (e.g Module = ranch_tcp), having
mod_cond not set to all means you need to specifically include it (or
include everything from the application), which is yet another extra
missing step.
The default should be to make it work, not to make it pretty and broken.
--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu
More information about the erlang-questions
mailing list