[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