| Age | Commit message (Collapse) | Author |
|---|
|
This adds a rel tuple to the reltool release specific configuration
format as {rel, Name, Vsn, RelApps, Opts} to support the use of
{rel, Name, Vsn, RelApps, [{load_dot_erlang, false}]} for preventing
the insertion of {apply,{c,erlangrc,[]}} into the release script file
and the release boot file.
This change makes it possible to prevent releases generated with
reltool from attempting to load a ${HOME}/.erlang file which is
desirable for production deployment of Erlang, to have greater control
of what BEAM evaluates. The ${HOME}/.erlang file lacks visibility and
its location on the filesystem separate from where the release lives
means it can be misused in a way that lacks visibility.
|
|
|
|
|
|
Needed by escript and tools
|
|
* siri/string-new-api: (28 commits)
hipe (test): Do not use deprecated functions in string(3)
dialyzer (test): Do not use deprecated functions in string(3)
eunit (test): Do not use deprecated functions in string(3)
system (test): Do not use deprecated functions in string(3)
system (test): Do not use deprecated functions in string(3)
mnesia (test): Do not use deprecated functions in string(3)
Deprecate old string functions
observer: Do not use deprecated functions in string(3)
common_test: Do not use deprecated functions in string(3)
eldap: Do not use deprecated functions in string(3)
et: Do not use deprecated functions in string(3)
os_mon: Do not use deprecated functions in string(3)
debugger: Do not use deprecated functions in string(3)
runtime_tools: Do not use deprecated functions in string(3)
asn1: Do not use deprecated functions in string(3)
compiler: Do not use deprecated functions in string(3)
sasl: Do not use deprecated functions in string(3)
reltool: Do not use deprecated functions in string(3)
kernel: Do not use deprecated functions in string(3)
hipe: Do not use deprecated functions in string(3)
...
Conflicts:
lib/eunit/src/eunit_lib.erl
lib/observer/src/crashdump_viewer.erl
lib/reltool/src/reltool_target.erl
|
|
|
|
|
|
|
|
|
|
Since file names on windows are unicode, and erl.ini contains paths to
'Bindir' and 'Rootdir', this file is now encoded in UTF-8.
|
|
|
|
|
|
|
|
The rel specification now dictates the order in which included and
used applications are loaded/started by the boot file. If the
applications are not specified in the rel spec, then the order from
the .app file is used. This was a bug earlier reported on systools,
and is now also implemented in reltool.
Example:
If a .app file specified
{applications,[x,y]}
{included_applications,[b,c]}
And the reltool.config has
{rel, "myrel", "1.0", [a,y,x,c,b]}
Then the boot file will load/start y before x and c before b. Earlier
x would always be started before y and b always before c due to the
order in the .app file.
|
|
If a 'rel' spec in the reltool config does not contain all
applications that are listed as {applications,Applications} in a .app
file, then these applications are autmatically added when creating the
.rel file.
For 'included_applications', the behaviour was not the same. I.e. if a
'rel' spec in the reltool config did not contain all applications that
are listed as {included_applications,InclApplications} in a .app file,
then reltool would fail with reason "Undefined applications" when
creating the .rel file. This has been corrected, so both
'applications' and 'included_applications' are now automatically added
if not already in the 'rel' spec.
I.e. for an application 'z', if z.app contains
{applications,[stdlib,kernel,x]}
{included_applications,[y]}
then reltool configuration
{rel, "myrel", "1.0", [z]}
will cause the same .rel file as
{rel, "myrel", "1.0", [stdlib,kernel,x,y,z]}
|
|
The erl.ini file generated by reltool:install/2 faulty pointed out
$ROOT/bin as Bindir. This is now changed to $ROOT/erts-Vsn/bin. Also,
backslashes in erl.ini needed to be escaped.
|
|
With this option reltool will create a target structure with only the
applications found in specified 'lib_dirs' (on system level) or
'lib_dir' (on app level). Erts will not be included, and no
applications found under $OTP_ROOT/lib.
|
|
* siri/reltool/app-level-lib-dir/OTP-9977:
[reltool] Allow lib_dir on app level to use relative path
[reltool] Add configuration parameter lib_dir on application level
|
|
* jc/omit-undefined-start_phases-3:
Avoid undefined start_phases entry in .script
Avoid creating an undefined start_phases entry when generating a release
OTP-10003
|
|
As a way of specifying one specific version of an application, the
following configuration parameter is added on application level:
{lib_dir,Dir}, Dir = string()
This can be useful if the parent directory of the application
directory is not suitable to use as a lib dir on system level.
|
|
OTP-9792
The following problems have been solved:
* reltool_target:do_merge_apps - in recursive calls to this function,
the accumulator was reverted each time causing the order of
applications listed after kernel and stdlib in the rel specification
in the configuration to sometimes be messed up.
* There are several ways to specify wich applications to include in an
application:
1) in the .app file for the including applications
2a) in the .rel file, when listing applications
2b) in the rel specification in the reltool configuration
2a (systools) and 2b (reltool) should have the same effect and
overwrite 1.
According to the documentation of systools (sasl), the default value
in 2a is an empty list. This should mean that if included
applications are not mentioned in the .rel file, then any included
application listed in the .app file will be disregarded. This is NOT
the way systools actually works. The implementation sets the default
for the .rel file to the same list as in the .app file.
Reltool earlier implemented 2b as described in the systools
documentation. However, after some discussion we decided to change
this so that reltool handles 2b in the same way as systools handles
2a since this seems more intuitive. The sasl documentation will be
altered accordingly (internal ref OTP-9980).
* If the rel specification in the reltool configuration explicitly
specified included applications to be an empty list, and the .app
file had a non-empty list, then the empty list from the rel
specification was discarded. This has been corrected so the rel
specification now, if set, always overwrites the value of
included_applications in the .app file.
* reltool would earlier add load instructions in the script/boot files
for ALL modules in the ebin directory of an application even if
mod_cond was set to app (include only modules listed in the .app
file). This has been corrected - now only modules with
#mod.is_included==true are loaded.
* reltool would earlier add start instructions in the script/boot file
for included applications. This has been corrected - included
applications shall only be loaded since the including application is
responsible for starting them.
|
|
OTP-9968
Make sure that inlined applications in an escript is included/excluded
as the escript itself, and forbid explicit configuration of the
inlined application.
|
|
When a release is generated and the applications in the release do not
define a value for the start_phases entry of their .app files, reltool
will generate the following entry in the .app files of the release:
{start_phases, undefined}
If this happens, when trying to create a release upgrade systools will
fail because it doesn't allow the start_phases entry to be set to
undefined. This patch avoids this situation by not generating a
start_phases entry when it is set to undefined.
|
|
|
|
While at it, applied some cleanups and code modernizations suggested by tidier.
|
|
|
|
|
|
It is for embedded systems where all included applications must be
loaded from the boot script. If embedded_app_type is set to something
else than undefined all included applications will be included in
both the "rel" as well as in the "script".
|
|
Applications that are required to be started
before other applications according to their
app-file are now automatically included in
the release. The kernel and stdlib applications
are automatically included.
|
|
|
|
It is called reltool:get_status/1. The API functions in reltool
that may take PidOrOptions as input and actually gets Options
does now print out the warnings.
|
|
Applications that are listed in a release are now
automatically included.
|
|
While at it, adapt the source files to fit within 80 chars and
remove trailing whitespace.
|
|
|
|
|
