[erlang-questions] Deploying on a server with different architecture and version of Erlang

[Anders Nygren]

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

/Anders

>
> But even with that reltool might not find all the modules it needs if you
> just use {mod_cond, derived}, especially if some of the modules are only
> used dynamically. If you really need to use this option, you'll want to
> check it included everything you use and test it properly. The new option to
> not include erts in releases is a much better and easier option if you want
> a small release in my opinion.
>
> --
> Loďc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu