reltool

2009 2009 Ericsson AB, All Rights Reserved The contents of this file are subject to the Erlang Public License, Version 1.1, (the "License"); you may not use this file except in compliance with the License. You should have received a copy of the Erlang Public License along with this software. If not, it can be retrieved online at http://www.erlang.org/. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. The Initial Developer of the Original Code is Ericsson AB. reltool Håkan Mattsson Håkan Mattsson Håkan Mattsson %VSN%

reltool Main API of the Reltool application

This is an interface module for the Reltool application.

Reltool is a release management tool. It analyses a given Erlang/OTP installation and determines various dependencies between applications. The graphical frontend depicts the dependencies and enables interactive customization of a target system. The backend provides a batch interface for generation of customized target systems.

The tool uses an installed Erlang/OTP system as input. root_dir is the root directory of the analysed system and it defaults to the system executing reltool. Applications may also be located outside root_dir. lib_dirs defines additional library directories where applications additional may reside and it defaults to the the directories listed by the operating system environment variable ERL_LIBS. See the module code for more info. Finally single modules and entire applications may be read from Escripts.

Some configuration parameters control the behavior of Reltool on system (sys) level. Others provide control on application (app) level and yet others are on module (mod) level. Module level parameters overrides application level parameters and application level parameters overrides system level parameters. Escript escript level parameters overrides system level parameters.

The following top level options are supported:

This is the main option and it controls the configuration of reltool. It can either be a sys tuple or a name of a file containing a sys tuple.

This option controls the error handling behavior of reltool. By default the window processes traps exit, but this behavior can altered by setting trap_exit to false.

This option controls the debug level of wx. As its name indicates it is only useful for debugging. See wx:debug/1 for more info.

Besides the already mentioned source parameters root_dir and lib_dirs, the following system (sys) level options are supported:

Erts specific configuration. See application level options below.

Escript specific configuration. An escript has a mandatory file name and escript level options that are described below.

Application specific configuration. An application has a mandatory name and application level options that are described below.

This parameter controls the module inclusion policy. It defaults to all which means that if an application is included (either explicitly or implicitly) all modules in that application will be included. This implies that both modules that exists on the ebin directory of the application, as well as modules that are named in the app file will be included. If the parameter is set to ebin, both modules on the ebin directory and derived modules are included. If the parameter is set to app, both modules in the app file and derived modules are included. derived means that only modules that are used by other included modules are included. The mod_cond setting on system level is used as default for all applications.

This parameter controls the application and escript inclusion policy. It defaults to derived which means that the applications that not have any explicit incl_cond setting, will only be included if any other (explicitly or implicitly included) application uses it. The value include implies that all applications and escripts that that not have any explicit incl_cond setting will be included. exclude implies that all applications and escripts) that that not have any explicit incl_cond setting will be excluded.

A target system may have several releases but the one given as boot_rel will be used as default when the system is booting up.

Release specific configuration. Each release maps to a rel, script and boot file. See the module systools for more info about the details. Each release has a name, a version and a set of applications with a few release specific parameters such as type and included applications.

This parameter controls whether the erl executable in the target system automatically should determine where it is installed or if it should use a hardcoded path to the installation. In the latter case the target system must be installed with reltool:install/2 before it can be used. If the system is relocatable, the file tree containing the target system can be moved to another location without re-installation. The default is true.

The creation of the specification for a target system is performed in two steps. In the first step a complete specification is generated. It will likely contain much more files than you are interested in your customized target system. In the second step the specification will be filtered according to your filters. There you have the ability to specify filters per application as well as system wide filters. You can also select a profile for your system. Depending on the profile, different default filters will be used. There are three different profiles to choose from: development, embedded and standalone. development is default. The parameters that are affected by the profile are: incl_sys_filters, excl_sys_filters, incl_app_filters and excl_app_filters.

This parameter controls the default handling of the app files when a target system is generated. It defaults to keep which means that app files are copied to the target system and their contents are kept as they are. strip means that a new app file is generated from the contents of the original app file where the non included modules are removed from the file. all does also imply that a new app file is generated from the contents of the original app file, with the difference that all included modules are added to the file. If the application does not have any app file a file will be created for all but not for keep and strip.

The debug_info parameter controls whether the debug information in the beam file should be kept (keep) or stripped strip when the file is copied to the target system.

This parameter normally contains a list of regular expressions that controls which files in the system that should be included. Each file in the target system must match at least one of the listed regular expressions in order to be included. Further the files may not match any filter in excl_sys_filters in order to be included. Which application files that should be included are controlled with the parameters incl_app_filters and excl_app_filters. This parameter defaults to [".*"].

This parameter normally contains a list of regular expressions that controls which files in the system that not should be included in the target system. In order to be included, a file must match some filter in incl_sys_filters but not any filter in excl_sys_filters. This parameter defaults to [].

This parameter normally contains a list of regular expressions that controls which application specific files that should be included. Each file in the application must match at least one of the listed regular expressions in order to be included. Further the files may not match any filter in excl_app_filters in order to be included. This parameter defaults to [".*"].

This parameter normally contains a list of regular expressions that controls which application specific files that not should be included in the target system. In order to be included, a file must match some filter in incl_app_filters but not any filter in excl_app_filters. This parameter defaults to [].

This parameter normally contains a list of regular expressions that controls which top level directories in an application that should be included in an archive file (as opposed of beeing included as a regular directory outside the archive). Each top directory in the application must match at least one of the listed regular expressions in order to be included. Further the files may not match any filter in excl_app_filters in order to be included. This parameter defaults to [".*"].

This parameter normally contains a list of regular expressions that controls which top level directories in an application that not should be included in an archive file. In order to be included in the application archive, a top directory must match some filter in incl_archive_filters but not any filter in excl_archive_filters. This parameter defaults to ["^include$","^priv$"].

This parameter contains a list of options that are given to zip:create/3 when application specific files are packaged into an archive. All options are not supported. The most useful options in this context, are the ones that controls which types of files that should be compressed. This parameter defaults to [].

On application (escript) level,the following options are supported:

The value of this parameter overrides the parameter with the same name on system level.

On application (app) level,the following options are supported:

The version of the application. In an installed system there may exist several versions of an application. The vsn parameter controls which version of the application that will be choosen. If it is omitted, the latest version will be choosen.

Module specific configuration. A module has a mandatory name and module level options that are described below.

The value of this parameter overrides the parameter with the same name on system level.

On module (mod) level,the following options are supported:

This parameter controls whether the module is included or not. By default the mod_incl parameter on application and system level will be used to control whether the module is included or not. The value of incl_cond overrides the module inclusion policy. include implies that the module is included, while exclude implies that the module not is included. derived implies that the is included if any included uses the module.

The value of this parameter overrides the parameter with the same name on application level.

DATA TYPES

create_target(Server, TargetDir) -> ok | {error, Reason} Create a target system Server = server() TargetDir = target_dir() Reason = reason()

Create a target system. Gives the same result as {ok,TargetSpec}=reltool:get_target_spec(Server) and reltool:eval_target_spec(TargetSpec,RootDir,TargetDir).

eval_target_spec(TargetSpec, RootDir, TargetDir) -> ok | {error, Reason} Create a target system TargetSpec = target_spec() RootDir = root_dir() TargetDir = target_dir() Reason = reason()

Create the actual target system from a specification generated by reltool:get_target_spec/1. The creation of the specification for a target system is performed in two steps. In the first step a complete specification will be generated. It will likely contain much more files than you are interested in in your target system. In the second step the specification will be filtered according to your filters. There you have the ability to specify filters per application as well as system wide filters. You can also select a profile for your system. Depending on the profile, different default filters will be used.

The top directories bin, releases and lib are treated differently from other files. All other files are by default copied to the target system. The releases directory contains generated rel, script, and boot files. The lib directory contains the applications. Which applications that are included and if they should be customized (archived, stripped from debug info etc.) is specified with various configuration parameters. The files in the bin directory are copied from the erts-vsn/bin directory, but only those files that was originally included in bin directory of the source system.

If the configuration parameter relocatable was set to true there is no need to install the target system with reltool:install/2 before it can be started. In that case the file tree containing the target system can be moved without re-installation.

get_config(Server) -> {ok, Config} | {error, Reason} Get reltool configuration Server = server() Config = config() Reason = reason()

Get reltool configuration. Shorthand for reltool:get_config(Server,false,false).

get_config(Server, InclDefaults, InclDerived) -> {ok, Config} | {error, Reason} Get reltool configuration Server = server() InclDefaults = incl_defaults() InclDerived = incl_derived() Config = config() Reason = reason()

Get reltool configuration. Normally, only the explicit configuration parameters with values that differs from their defaults are interesting. But the builtin default values can be returned by setting InclDefaults to true. The derived configuration can be return by setting InclDerived to true.

get_rel(Server, Relname) -> {ok, RelFile} | {error, Reason} Get contents of a release file Server = server() RelName = rel_name() RelFile = rel_file() Reason = reason()

Get contents of a release file. See rel(4) for more details.

get_script(Server, Relname) -> {ok, ScriptFile | {error, Reason} Get contents of a boot script file Server = server() RelName = rel_name() ScriptFile = script_file() Reason = reason()

Get contents of a boot script file. See script(4) for more details.

get_status(Server) -> {ok, [Warning]} | {error, Reason} Get contents of a release file Server = server() Warning = string() Reason = reason()

Get status about the configuration

get_server(WindowPid) -> {ok, ServerPid} | {error, Reason} Start server process with options WindowPid = window_pid() ServerPid = server_pid() Reason = reason()

Return the process identifier of the server process.

get_target_spec(Server) -> {ok, targetSpec} | {error, Reason} Return a specification of the target system Server = server() TargetSpec = target_spec() Reason = reason()

Return a specification of the target system. The actual target system can be created with reltool:eval_target_spec/3.

install(Server, TargetDir) -> ok | {error, Reason} Install a target system Server = server() TargetDir = target_dir() Reason = reason()

Install a created target system

start() -> {ok, WindowPid} | {error, Reason} Start main window process WindowPid = window_pid() Reason = reason()

Start a main window process with default options

start(Options) -> {ok, WindowPid} | {error, Reason} Start main window process with options Options = options() WindowPid = window_pid() Reason = reason()

Start a main window process with options

start_link(Options) -> {ok, WindowPid} | {error, Reason} Start main window process with options Options = options() WindowPid = window_pid() Reason = reason()

Start a main window process with options. The process is linked.

start_server(Options) -> {ok, ServerPid} | {error, Reason} Start server process with options Options = options() ServerPid = server_pid() Reason = reason()

Start a server process with options. The server process identity can be given as argument to several other functions in the API.

stop(Pid) -> ok | {error, Reason} Stop a server or window process Pid = server_pid() | window_pid()() Reason = reason()

Stop a server or window process