[erlang-questions] Running rebar generated release failing with Kernel pid terminated"

[Loïc Hoguin]

On 12/13/2012 01:54 PM, Loïc Hoguin wrote:
> 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.

Taking this off-list, no need to pollute the ML more. :)

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu