[erlang-questions] Meaning of the 'local' option atom in systools:make_script/2
Siri Hansen
erlangsiri@REDACTED
Wed Feb 5 16:36:28 CET 2014
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 <ivan@REDACTED>:
> 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 <erlangsiri@REDACTED> 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 <ivan@REDACTED>:
>
>> 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
>>
>> ivan@REDACTED
>> www.llaisdy.com
>> llaisdy.wordpress.com
>> github.com/llaisdy
>> www.linkedin.com/in/ivanuemlianin
>>
>> festina lente
>> ============================================================
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140205/2ff49b7d/attachment.htm>
More information about the erlang-questions
mailing list