[erlang-questions] Meaning of the 'local' option atom in systools:make_script/2

Ivan Uemlianin <>
Wed Feb 5 17:42:28 CET 2014


Thanks. Will try it out.

Ivan

--
festina lente


> On 5 Feb 2014, at 15:36, Siri Hansen <> wrote:
> 
> 1) yes
> 
> 2) you don't need to fetch required apps *before* run make_script. In order to run make_script you only need the erlang node to have a path to where your applications are located (or use the 'path' option to make_script). You do however need to have your applications under $ROOT/lib/ before you start your erlang node with the generated <relname>.boot file.
> 
> /siri
> 
> 
> 2014-02-05 Ivan Uemlianin <>:
>> Dear Siri
>> 
>> Thanks!
>> 
>> So it looks like answer #1 is yes; answer #2 is I should fetch the required apps and put them in lib *before* running make_script.
>> 
>> Best wishes
>> 
>> Ivan
>> 
>> --
>> festina lente
>> 
>> 
>>> On 5 Feb 2014, at 15:15, Siri Hansen <> wrote:
>>> 
>>> Hi Ivan!
>>> 
>>> First, be aware that systools:make_script/[1,2] does not fetch any erlang applications or create any kind of a release package, it only creates <relname>.script and <relname>.boot from the given <relname>.rel file. <relname>.script is a text file and <relname>.boot is a binary version of the same. The .boot file is used when starting an erlang node to give the initial information about which applications to start and where to find them.
>>> 
>>> From the same .rel file, I have run make_script, once with 'local' and once without it. Running diff on the two generated .script files does only give results like this:
>>> 
>>> 14c12
>>> <      {path,["/ldisk/siri/git/otp/lib/kernel/ebin"]},
>>> ---
>>> >      {path,["$ROOT/lib/kernel-3.0/ebin"]},
>>> 
>>> So, what does it mean? It means that if I use 'local', then I can start my erlang node with the created <relname>.boot and it will pick all applications from the exact same place as the erlang node from which I executed systools:make_script. This is mostly intended for testing!
>>> 
>>> A .boot file created without 'local' is intended to use in a "real" release, which could e.g. be created with systools:make_tar etc. The point beeing that you can create your .script/.boot at build time, without the knowledge about the installation destination. It is assumed that the installation is structured in a standard OTP way with all applications under a $ROOT/lib (this can, however, be omitted by using the 'variables' option to make_script - see documentation). When starting the erlang node with this .boot file, $ROOT will be replaced with the real root dir of the installation.
>>> 
>>> Regards
>>> /siri
>>> 
>>> 
>>> 
>>> 2014-02-04 Ivan Uemlianin <>:
>>>> Dear All
>>>> 
>>>> What is the meaning of the 'local' option atom in systools:make_script/2?
>>>> 
>>>> My understanding of the erlang documentation [1] is that, if 'local' is given, make_script will find paths to the application directories on the current file system, and it will use those paths in the release script.  Nothing is copied into the release directory structure.  A release built with 'local' will only be portable to another system if that system has exactly the same applications at exactly the same paths.  If I would like the release to be portable, I should omit 'local' and make sure all required applications are in a lib/ directory in the release directory structure.
>>>> 
>>>> This seems to be more-or-less what "Erlang and OTP in Action" says [2], but "Learn You Some Erlang" seems to say the exact opposite [3].
>>>> 
>>>> So my questions are:
>>>> 
>>>> 1.  Do I understand the documentation correctly?
>>>> 
>>>> 2.  If I omit 'local' will make_scripts/2 fetch the required erlang applications and put them in lib/, or must I do that myself?
>>>> 
>>>> With thanks and best wishes
>>>> 
>>>> Ivan
>>>> 
>>>> 
>>>> ** [1] erlang documentation
>>>> 
>>>> http://www.erlang.org/doc/man/systools.html#make_script-2
>>>> 
>>>>     In the generated boot script all application directories are
>>>>     structured as App-Vsn/ebin and assumed to be located in $ROOT/lib,
>>>>     where $ROOT is the root directory of the installed release. If the
>>>>     local option is supplied, the actual directories where the
>>>>     applications were found are used instead. This is a useful way to
>>>>     test a generated boot script locally.
>>>> 
>>>> 
>>>> ** [2] Erlang and OTP in Action (2011)
>>>> 
>>>> Ch 10. Packaging, services and deployment, p. 250
>>>> 
>>>>     1> systools:make_script("simple_cache", [local]).
>>>>     ok
>>>> 
>>>>     The local option ... stipulates that absolute paths to all
>>>>     applications are written in the script and boot files --- meaning
>>>>     that if you try to start a system using this boot file, all
>>>>     application code must reside in exactly the same place it did when
>>>>     the boot file was created.  The local option is good for testing,
>>>>     but it isn't very portable and may not be suitable for production.
>>>> 
>>>>     Without the local option, the generated script and boot files
>>>>     expect that all applications are located in a directory called lib,
>>>>     pointed out by a system variable $ROOT.  This is suitable for a
>>>>     release that you want to be able to install on different host
>>>>     machines that don't necessarily have the same paths.
>>>> 
>>>> 
>>>> ** [3] Learn You Some Erlang (2013)
>>>> 
>>>> Ch 21. Release is the Word, p. 340
>>>> 
>>>>     1> systools:make_script("erlcount-1.0", [local]).
>>>>     ok
>>>> 
>>>>     Here, the local option means that we want the release to be
>>>>     possible to run from anywhere, and not just the current install.
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> ============================================================
>>>> Ivan A. Uemlianin PhD
>>>> Llaisdy
>>>> Speech Technology Research and Development
>>>> 
>>>>                     
>>>>                      www.llaisdy.com
>>>>                          llaisdy.wordpress.com
>>>>               github.com/llaisdy
>>>>                      www.linkedin.com/in/ivanuemlianin
>>>> 
>>>>                         festina lente
>>>> ============================================================
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> 
>>>> http://erlang.org/mailman/listinfo/erlang-questions
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140205/15d169ba/attachment.html>


More information about the erlang-questions mailing list