| Age | Commit message (Collapse) | Author |
|---|
|
For applications that are explicitly included in the reltool config,
but that are not included in a 'rel' spec, dependencies in the .app
file are not followed (only xref dependencies are taken care of).
|
|
|
|
|
|
reltool_server_SUITE:create_standalone and create_multiple_standalone
failed on test hosts running hipe and smp. The reason was that the
escript used in these tests explicitly disabled smp, which in turn
made the emulator spit out warnings like this:
"<HiPE (v 3.10)> Warning: not loading native code for module beam_lib:
it was compiled for an incompatible runtime system; please regenerate
native code for this runtime system"
This was returned from the escript and did not match the expected result.
To overcome this, the escript (reltool/examples/display_args) is
changed and does no longer disable smp.
|
|
|
|
In the first traversal of library directories, reltool used only the
directory names in order to figure out application names. This would
succeed if the directory name was AppName only or AppName-AppVsn and
AppVsn consisted of integers separated by dots only. If the AppVsn has
any other format, then reltool would not find the correct application
name.
With this commit, reltool will first look for a .app file and use the
.app file name as the application name. This will allow different
formats of the version identifier in the directory name. Note that
reltool can still not sort (and select the latest) amongst version
identifiers of other format than integers separated by dots.
|
|
According to documentation it should be allowed to set
incl_cond=include|exclude|derived, but if set to derived on module
level, reltool_server would crash. This has been corrected.
|
|
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.
|
|
This commit adds a normalization of the directory given with the
lib_dir parameter on application level. This will covert the path to
absolute, remove trailing slash and any occurrencies of "xxx/..".
|
|
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-9792
Earlier this would cause an error with reason
"Module xxx potentially included by two different applications: yyy and yyy."
This is now changed so it will only be a warning saying that the
module is duplicated in the .app file.
|
|
OTP-9794
OTP-9968
The following test cases are added:
* create_standalone_beam
* create_standalone_app
* create_multiple_standalone
* load_config_escript_path
* load_config_same_escript_source
* load_config_same_escript_beam
* load_config_add_escript
Most of them are temporarily skipped since they re-produce known
problems that will be corrected in a later commit.
|
|
OTP-9794
Test cases create_release_sort and create_script_sort are added. The
test are temporarily skipped since they detected quite a few bugs that
will be corrected with OTP-9792.
The following bug is corrected in this commit:'
reltool_server did not recognize {App,InclApps} inside a 'rel'
specification in the reltool config, e.g.
{rel, "myrel", "1.0", [{myapp,[app2]}]}.
|
|
OTP-9794
This is a test of the mechanism with which reltool_server decides
which applications to include and not, based on function calls between
applications. This is also the mechanism which forms the base for the
application- and module dependency graphs.
|
|
OTP-9794
The following test cases are added for the inteface from GUI to
reltool_server:
* get_config
* get_apps
* set_app_and_undo
* set_apps_and_undo
* load_config_and_undo
* reset_config_and_undo
* save_config
The following bugs were found and corrected:
* If set_apps failed, then the state of reltool_server would not
be reset to how it was before the failing operation - and every
operation done afterwards would also (seem to) fail.
* undo_config did not work after reset_config - since faulty #sys
record was stored as old_sys.
* undo_config did not work after set_app (used when changing the
content of an application from the GUI) - since old_sys was not
set. Also old_status was not set causing possible warnings to
disappear.
* undo_config did not work after set_apps (used e.g. when
excluding or including an application from the GUI) - since
old_sys was not set. Also old_status was not set causing
possible warnings to disappear.
|
|
Earlier, reltool expected all module names detected under the lib
directories to have unique names. If this was not the case, the result
was undefined - i.e. the beam file of the duplicated module might be
included in multiple applications in the target area, or it might even
be excluded from all applications.
This commit adds awareness in reltool that a module might occur in
multiple applications, and it is allowed as long as the module or it's
application is explicitely excluded in all but one of the containing
applications.
|
