diff options
Diffstat (limited to 'lib/reltool/doc/src')
| -rw-r--r-- | lib/reltool/doc/src/Makefile | 14 | ||||
| -rw-r--r-- | lib/reltool/doc/src/make.dep | 20 | ||||
| -rw-r--r-- | lib/reltool/doc/src/notes.xml | 160 | ||||
| -rw-r--r-- | lib/reltool/doc/src/reltool.xml | 91 |
4 files changed, 247 insertions, 38 deletions
diff --git a/lib/reltool/doc/src/Makefile b/lib/reltool/doc/src/Makefile index 8bc1488f77..0b85b7e02c 100644 --- a/lib/reltool/doc/src/Makefile +++ b/lib/reltool/doc/src/Makefile @@ -97,13 +97,13 @@ clean clean_docs: include $(ERL_TOP)/make/otp_release_targets.mk release_docs_spec: docs - $(INSTALL_DIR) $(RELSYSDIR)/doc/pdf - $(INSTALL_DATA) $(TOP_PDF_FILE) $(RELSYSDIR)/doc/pdf - $(INSTALL_DIR) $(RELSYSDIR)/doc/html - $(INSTALL_DATA) $(HTMLDIR)/* $(RELSYSDIR)/doc/html - $(INSTALL_DATA) $(INFO_FILE) $(RELSYSDIR) - $(INSTALL_DIR) $(RELEASE_PATH)/man/man3 - $(INSTALL_DATA) $(MAN3DIR)/* $(RELEASE_PATH)/man/man3 + $(INSTALL_DIR) "$(RELSYSDIR)/doc/pdf" + $(INSTALL_DATA) $(TOP_PDF_FILE) "$(RELSYSDIR)/doc/pdf" + $(INSTALL_DIR) "$(RELSYSDIR)/doc/html" + $(INSTALL_DATA) $(HTMLDIR)/* "$(RELSYSDIR)/doc/html" + $(INSTALL_DATA) $(INFO_FILE) "$(RELSYSDIR)" + $(INSTALL_DIR) "$(RELEASE_PATH)/man/man3" + $(INSTALL_DATA) $(MAN3DIR)/* "$(RELEASE_PATH)/man/man3" release_spec: diff --git a/lib/reltool/doc/src/make.dep b/lib/reltool/doc/src/make.dep deleted file mode 100644 index 59e77e8162..0000000000 --- a/lib/reltool/doc/src/make.dep +++ /dev/null @@ -1,20 +0,0 @@ -# ---------------------------------------------------- -# >>>> Do not edit this file <<<< -# This file was automaticly generated by -# /home/otp/bin/docdepend -# ---------------------------------------------------- - - -# ---------------------------------------------------- -# TeX files that the DVI file depend on -# ---------------------------------------------------- - -book.dvi: book.tex part.tex ref_man.tex reltool.tex \ - reltool_examples.tex reltool_intro.tex reltool_usage.tex - -# ---------------------------------------------------- -# Source inlined when transforming from source to LaTeX -# ---------------------------------------------------- - -book.tex: ref_man.xml - diff --git a/lib/reltool/doc/src/notes.xml b/lib/reltool/doc/src/notes.xml index 5304b996a4..0aae128c2b 100644 --- a/lib/reltool/doc/src/notes.xml +++ b/lib/reltool/doc/src/notes.xml @@ -37,7 +37,165 @@ thus constitutes one section in this document. The title of each section is the version number of Reltool.</p> - <section><title>Reltool 0.5.7</title> + <section><title>Reltool 0.6</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Miscellaneous corrections: <list> <item> Start of reltool + GUI would sometimes crash with a badmatch in + reltool_sys_win:do_init. This has been corrected. </item> + <item> Minor corrections of documentation and type + specifications of app() and mod() are done. </item> + <item> If a module name is duplicated in an app file + reltool would return an error. This is now changed to a + warning. </item> <item> Reltool would earlier not + necessarily keep the order of applications as listed in + the rel specification in the configuration. This has been + corrected. </item> <item> Reltool would earlier set the + default for included applications to an empty list if it + was not set in the rel specification in the + configuration. This was correct according to + sasl/systools documentation, but not according to + sasl/systools implementation. We decided to change the + documentation and reltool to use the value of + included_applications from the .app file as default + instead of the empty list, since this seems more + intuitive and since systools always has done the same. + </item> <item> The value of included applications in the + rel specification in the configuration did not overwrite + included_applications in the .app file if it was set to + an empty list. This has been corrected. </item> <item> + 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. </item> <item> 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. </item> + <item> Status bar now indicates that reltool is working + (Processing libraries...) for all configuration changes, + and when generating target system. </item> <item> Title + of dependecies column in app and mod window is changed + from "Modules used by others" to "Modules using this". + </item> </list></p> + <p> + Own Id: OTP-9792</p> + </item> + <item> + <p> + Configuration changes via the GUI had a few bugs related + to error handling, rollback and undo. A major re-write of + the reltool_server has been done in order to align the + way reltool_server updates and uses its state and tables + for all different kinds of configuration change. </p> + <p> + All configuration changes (except undo) now cause a + re-read of the file system, meaning that if something has + changed in the file system it will be reflected in the + result of the configuration change.</p> + <p> + When loading a new configuration file via the GUI, the + old configuration is now completely scratched, and only + the new is valid.</p> + <p> + *** POTENTIAL INCOMPATIBILITY ***</p> + <p> + Own Id: OTP-9794</p> + </item> + <item> + <p> + Some bug fixes related to the handling of escripts: + <list> <item> Reltool could not handle escripts with + inlined applications. This has been corrected. Inlined + applications will be visible in the GUI, but not possible + to include/exclude separately. </item> <item> Loading a + config which contains an escript via the GUI menu did not + produce the same result as when using the same + configuration at reltool start. Paths, version and label + could differ. This has been corrected. </item> <item> + Loading config with same escript (source) twice caused + reltool to add same module twice. This has been + corrected. </item> <item> Loading config with same + escript (inlined beam) twice caused reltool to fail + saying module is included by two different applications. + This has been corrected. </item> <item> Loading config + which in addition to an existing escript also adds + another escript, for which the name sorts before the + existing one, would cause reltool to fail saying + "Application name clash". This has been corrected. + </item> </list></p> + <p> + Own Id: OTP-9968</p> + </item> + <item> + <p> + Reltool would sometimes generate a .app file containing + <c>{start_phases,undefined}</c>, which would cause an + exception in systools at parse time. This has been + corrected so reltool now omits the <c>start_phases</c> + entry if the value is <c>undefined</c>. (Thanks to Juan + Jose Comellas)</p> + <p> + In order to align with reltool, sasl will also omit + <c>start_phases</c> entries with value <c>undefined</c> + in .script files.</p> + <p> + Own Id: OTP-10003</p> + </item> + </list> + </section> + + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + A warning list is added to the sys window of the reltool + GUI. This list will continuously show all warnings + produced by the current configuration.</p> + <p> + Own Id: OTP-9967</p> + </item> + <item> + <p> + As a way of specifying one specific version of an + application, the following configuration parameter is + added on application level:</p> + <p> + {lib_dir,Dir}, Dir = string()</p> + <p> + This can be useful if the parent directory of the + application directory is not suitable to use as a lib dir + on system level.</p> + <p> + Own Id: OTP-9977</p> + </item> + </list> + </section> + +</section> + +<section><title>Reltool 0.5.7.1</title> + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Added recommendation about <c>RootDir</c> parameter to + <c>reltool:eval_target_spec/3</c>.</p> + <p> + Own Id: OTP-9742</p> + </item> + </list> + </section> + +</section> + +<section><title>Reltool 0.5.7</title> <section><title>Fixed Bugs and Malfunctions</title> <list> diff --git a/lib/reltool/doc/src/reltool.xml b/lib/reltool/doc/src/reltool.xml index 31e15e34e7..9b43640d83 100644 --- a/lib/reltool/doc/src/reltool.xml +++ b/lib/reltool/doc/src/reltool.xml @@ -5,7 +5,7 @@ <header> <copyright> <year>2009</year> - <year>2011</year> + <year>2012</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> @@ -221,6 +221,52 @@ system.</p> </item> + <tag><c>excl_lib</c></tag> + <item> + <warning><p>This option is experimental.</p></warning> + <p>If the <c>excl_lib</c> option is set to <c>otp_root</c> + then reltool will not copy anything from the Erlang/OTP + installation ($OTP_ROOT) into the target structure. The goal + is to create a "slim" release which can be used together with + an existing Erlang/OTP installation. The target structure will + therefore only contain a <c>lib</c> directory with the + applications that were found outside of $OTP_ROOT (typically + your own applications), and a <c>releases</c> directory with + the generated <c>.rel,</c> <c>.script</c> and <c>.boot</c> + files.</p> + + <p>When starting this release, three things must be specified:</p> + <taglist> + <tag><b>Which <c>releases</c> directory to use</b></tag> + <item>Tell the release handler to use the <c>releases</c> + directory in our target structure instead of + <c>$OTP_ROOT/releases</c>. This is done by setting the SASL + environment variable <c>releases_dir</c>, either from the + command line (<c>-sasl releases_dir + <target-dir>/releases</c>) or in + <c>sys.config</c>.</item> + + <tag><b>Which boot file to use</b></tag> + <item>The default boot file is <c>$OTP_ROOT/bin/start</c>, + but in this case we need to specify a boot file from our + target structure, typically + <c><target-dir>/releases/<vsn>/<RelName></c>. This + is done with the <c>-boot</c> command line option to + <c>erl</c></item> + + <tag><b>The location of our applications</b></tag> + <item>The generated .script (and .boot) file uses the + environment variable <c>$RELTOOL_EXT_LIB</c> as prefix for + the paths to all applications. The <c>-boot_var</c> option + to <c>erl</c> can be used for specifying the value of this + variable, typically <c>-boot_var RELTOOL_EXT_LIB + <target-dir>/lib</c>.</item> + </taglist> + + <p>Example:</p> + <p><code>erl -sasl releases_dir \"mytarget/releases\" -boot mytarget/releases/1.0/myrel -boot_var RELTOOL_EXT_LIB mytarget/lib</code></p> + </item> + <tag><c>incl_sys_filters</c></tag> <item> <p>This parameter normally contains a list of regular @@ -322,8 +368,21 @@ <item> <p>The version of the application. In an installed system there may exist several versions of an application. The <c>vsn</c> parameter - controls which version of the application will be chosen. If it - is omitted, the latest version will be chosen.</p> + controls which version of the application will be chosen.</p> + <p>This parameter is mutual exclusive with <c>lib_dir</c>. If + <c>vsn</c> and <c>lib_dir</c> are both omitted, the latest version + will be chosen.</p> + </item> + <tag><c>lib_dir</c></tag> + <item> + <p>The directory to read the application from. This parameter + can be used to point out a specific location to fetch the + application from. This is useful for instance if the parent + directory for some reason is no good as a library directory on + system level.</p> + <p>This parameter is mutual exclusive with <c>vsn</c>. If + <c>vsn</c> and <c>lib_dir</c> are both omitted, the latest version + will be chosen.</p> </item> <tag><c>mod</c></tag> <item> @@ -433,11 +492,13 @@ sys() = {root_dir, root_dir()} | {excl_archive_filters, excl_archive_filters()} | {archive_opts, [archive_opt()]} app() = {vsn, app_vsn()} - | {mod, mod_name(), mod()} + | {lib_dir, lib_dir()} + | {mod, mod_name(), [mod()]} | {mod_cond, mod_cond()} | {incl_cond, incl_cond()} | {debug_info, debug_info()} | {app_file, app_file()} + | {excl_lib, excl_lib()} | {incl_sys_filters, incl_sys_filters()} | {excl_sys_filters, excl_sys_filters()} | {incl_app_filters, incl_app_filters()} @@ -445,8 +506,7 @@ app() = {vsn, app_vsn()} | {incl_archive_filters, incl_archive_filters()} | {excl_archive_filters, excl_archive_filters()} | {archive_opts, [archive_opt()]} -mod() = {vsn, app_vsn()} - | {incl_cond, incl_cond()} +mod() = {incl_cond, incl_cond()} | {debug_info, debug_info()} rel_app() = app_name() | {app_name(), app_type()} @@ -464,6 +524,7 @@ escript() = {incl_cond, incl_cond()} escript_file() = file() excl_app_filters() = regexps() excl_archive_filters() = regexps() +excl_lib() = otp_root excl_sys_filters() = regexps() file() = string() incl_app() = app_name() @@ -558,7 +619,17 @@ target_spec() = [target_spec()] <c>true</c> there is no need to install the target system with <c>reltool:install/2</c> before it can be started. In that case the file tree containing the target system can be moved without - re-installation.</p></desc> + re-installation.</p> + + <p>In most cases, the <c>RootDir</c> parameter should be set to + the same as the <c>root_dir</c> configuration parameter used in + the call to <c>reltool:get_target_spec/1</c> + (or <c>code:root_dir()</c> if the configuration parameter is not + set). In some cases it might be useful to evaluate the same + target specification towards different root directories. This + should, however, be used with great care as it requires + equivalent file structures under all roots.</p> + </desc> </func> <func> @@ -640,7 +711,7 @@ target_spec() = [target_spec()] </func> <func> - <name>get_target_spec(Server) -> {ok, targetSpec} | {error, Reason}</name> + <name>get_target_spec(Server) -> {ok, TargetSpec} | {error, Reason}</name> <fsummary>Return a specification of the target system</fsummary> <type> <v>Server = server()</v> @@ -654,10 +725,10 @@ target_spec() = [target_spec()] </func> <func> - <name>install(Server, TargetDir) -> ok | {error, Reason}</name> + <name>install(RelName, TargetDir) -> ok | {error, Reason}</name> <fsummary>Install a target system</fsummary> <type> - <v>Server = server()</v> + <v>RelName = rel_name()</v> <v>TargetDir = target_dir()</v> <v>Reason = reason()</v> </type> |