[erlang-questions] Deploying on a server with different architecture and version of Erlang
Loïc Hoguin
essen@REDACTED
Sun Dec 16 13:02:53 CET 2012
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.
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
More information about the erlang-questions
mailing list