[erlang-questions] Meaning of the 'local' option atom in systools:make_script/2
Ivan Uemlianin
ivan@REDACTED
Tue Feb 4 10:28:25 CET 2014
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
============================================================
More information about the erlang-questions
mailing list