[erlang-questions] Dependencies on library applications (was: Deploying on a server with different architecture and version of Erlang)

Loïc Hoguin essen@REDACTED
Mon Dec 17 10:05:56 CET 2012

On 12/17/2012 04:48 AM, Anders Nygren wrote:
> On Sun, Dec 16, 2012 at 6:02 AM, Loïc Hoguin <essen@REDACTED> wrote:
>> On 12/14/2012 10:33 PM, Anders Nygren wrote:
>>> On Fri, Dec 14, 2012 at 11:09 AM, Vineet Naik <naikvin@REDACTED> wrote:
>>>> On Fri, Dec 14, 2012 at 9:39 PM, Daniel Luna <daniel@REDACTED> wrote:
>>>>> If this fixed your problem you have missing dependencies in your
>>>>> .app.src file.  We always run {mod_cond, derived} here and it works
>>>>> like a charm.
>>>>> Until you miss to add a dependency in the .app.src file that is.
>>>> Hi Daniel,
>>>> I am am not able to exactly understand which dependencies are to be added
>>>> in
>>>> app.src.
>>>> My code directly depends upon just two - emysql and exmpp (Not the
>>>> processone version
>>>> but this one [1] which is rebar compatible). Besides these, kernel and
>>>> stdlib are defined.
>>>> While creating a release on my development machine I could fix some
>>>> initial
>>>> errors by
>>>> adding inets, sasl and crypto. That solved the problems with mod_cond
>>>> still
>>>> being 'derived'
>>>> Today while creating a release on the server (where the app will be
>>>> deployed
>>>> eventually),
>>>> it again failed with `{"init terminating in do_boot",{'cannot
>>>> load',X,get_file}}` kind of errors
>>>> and adding 'X' to app.src didn't work. Changing mod_cond to 'all' worked.
>>>> Now if I check the libraries in rel/<release-bundle>/lib directory, there
>>>> are a lot of them
>>>> but not all are added to app.src and it still works.
>>>> How to decide which ones go in app.src and which don't?
>>> The ones to put in the .app.src are the applications that MUST be
>>> started* before Your app is started.
>>> This information is used when the .boot script is created, so that all
>>> the applications are started in the correct order.
>>> *, Yes, I know the documentation says that stdlib shall always be
>>> included even though stdlib doesn't have any processes that needs to
>>> be started.
>> Apparently does because stdlib is a library application and all library
>> applications return ok for application:start(App). I suppose you should put
>> all applications you depend on in there, not just applications that must be
>> started.
> In the documentation it says, in
> http://www.erlang.org/doc/design_principles/applications.html#id73720
> about the .app file
> "applications
> All applications which must be started before this application is
> started. systools uses this list to generate correct boot scripts.
> Defaults to [], but note that all applications have dependencies to at
> least kernel and stdlib."
> a few years ago I complained about an OTP application that did not
> list a library application that it depended on, but did not have to be
> started and was told that I was wrong.
> see, http://erlang.org/pipermail/erlang-bugs/2007-April/000333.html
> for more details


But, directing my question to OTP guys now, wouldn't it be simpler if 
we'd list library applications there too? Building releases would be 
much easier if all dependencies were listed somewhere and it appears 
this has no negative impact to put them in applications. Correct me if 
I'm wrong.

Loïc Hoguin
Erlang Cowboy
Nine Nines

More information about the erlang-questions mailing list