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:
config
-
This is the main option and it controls the configuration of
reltool
. It can either be asys
tuple or a name of afile
containing a sys tuple. trap_exit
-
This option controls the error handling behavior of
reltool
. By default the window processes traps exit, but this behavior can altered by settingtrap_exit
tofalse
. wx_debug
-
This option controls the debug level of
wx
. As its name indicates it is only useful for debugging. Seewx: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
-
Erts specific configuration. See application level options below.
escript
-
Escript specific configuration. An escript has a mandatory file name and escript level options that are described below.
app
-
Application specific configuration. An application has a mandatory name and application level options that are described below.
mod_cond
-
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 theebin
directory of the application, as well as modules that are named in theapp
file will be included. If the parameter is set toebin
, both modules on theebin
directory and derived modules are included. If the parameter is set toapp
, both modules in theapp
file and derived modules are included.derived
means that only modules that are used by other included modules are included. Themod_cond
setting on system level is used as default for all applications. incl_cond
-
This parameter controls the application and escript inclusion policy. It defaults to
derived
which means that the applications that not have any explicitincl_cond
setting, will only be included if any other (explicitly or implicitly included) application uses it. The valueinclude
implies that all applications and escripts that that not have any explicitincl_cond
setting will be included.exclude
implies that all applications and escripts) that that not have any explicitincl_cond
setting will be excluded. boot_rel
-
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. rel
-
Release specific configuration. Each release maps to a
rel
,script
andboot
file. See the modulesystools
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. relocatable
-
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 withreltool: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 istrue
. profile
-
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 theprofile
, different default filters will be used. There are three different profiles to choose from:development
,embedded
andstandalone
.development
is default. The parameters that are affected by theprofile
are:incl_sys_filters
,excl_sys_filters
,incl_app_filters
andexcl_app_filters
. app_file
-
This parameter controls the default handling of the
app
files when a target system is generated. It defaults tokeep
which means thatapp
files are copied to the target system and their contents are kept as they are.strip
means that a newapp
file is generated from the contents of the originalapp
file where the non included modules are removed from the file.all
does also imply that a newapp
file is generated from the contents of the originalapp
file, with the difference that all included modules are added to the file. If the application does not have anyapp
file a file will be created forall
but not forkeep
andstrip
. debug_info
-
The
debug_info
parameter controls whether the debug information in the beam file should be kept (keep
) or strippedstrip
when the file is copied to the target system. incl_sys_filters
-
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 parametersincl_app_filters
andexcl_app_filters
. This parameter defaults to[".*"]
. excl_sys_filters
-
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 inexcl_sys_filters
. This parameter defaults to[]
. incl_app_filters
-
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[".*"]
. excl_app_filters
-
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 inexcl_app_filters
. This parameter defaults to[]
. incl_archive_filters
-
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[".*"]
. excl_archive_filters
-
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 inexcl_archive_filters
. This parameter defaults to["^include$","^priv$"]
. archive_opts
-
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:
incl_cond
-
The value of this parameter overrides the parameter with the same name on system level.
On application (app
) level,the following options are
supported:
vsn
-
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. mod
-
Module specific configuration. A module has a mandatory name and module level options that are described below.
mod_cond
-
The value of this parameter overrides the parameter with the same name on system level.
incl_cond
-
The value of this parameter overrides the parameter with the same name on system level.
app_file
-
The value of this parameter overrides the parameter with the same name on system level.
debug_info
-
The value of this parameter overrides the parameter with the same name on system level.
incl_app_filters
-
The value of this parameter overrides the parameter with the same name on system level.
excl_app_filters
-
The value of this parameter overrides the parameter with the same name on system level.
incl_archive_filters
-
The value of this parameter overrides the parameter with the same name on system level.
excl_archive_filters
-
The value of this parameter overrides the parameter with the same name on system level.
archive_opts
-
The value of this parameter overrides the parameter with the same name on system level.
On module (mod
) level,the following options are
supported:
incl_cond
-
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 ofincl_cond
overrides the module inclusion policy.include
implies that the module is included, whileexclude
implies that the module not is included.derived
implies that the is included if any included uses the module. debug_info
-
The value of this parameter overrides the parameter with the same name on application level.
DATA TYPES
options() = [option()] option() = {config, config() | file()} | {trap_exit, bool()} | {wx_debug, term()} config() = {sys, [sys()]} sys() = {root_dir, root_dir()} | {lib_dirs, [lib_dir()]} | {profile, profile()} | {erts, app()} | {escript, escript_file(), [escript()]} | {app, app_name(), [app()]} | {mod_cond, mod_cond()} | {incl_cond, incl_cond()} | {boot_rel, boot_rel()} | {rel, rel_name(), rel_vsn(), [rel_app()]} | {relocatable, relocatable()} | {app_file, app_file()} | {debug_info, debug_info()} | {incl_sys_filters, incl_sys_filters()} | {excl_sys_filters, excl_sys_filters()} | {incl_app_filters, incl_app_filters()} | {excl_app_filters, excl_app_filters()} | {incl_archive_filters, incl_archive_filters()} | {excl_archive_filters, excl_archive_filters()} | {archive_opts, [archive_opt()]} app() = {vsn, app_vsn()} | {mod, mod_name(), mod()} | {mod_cond, mod_cond()} | {incl_cond, incl_cond()} | {debug_info, debug_info()} | {app_file, app_file()} | {incl_sys_filters, incl_sys_filters()} | {excl_sys_filters, excl_sys_filters()} | {incl_app_filters, incl_app_filters()} | {excl_app_filters, excl_app_filters()} | {incl_archive_filters, incl_archive_filters()} | {excl_archive_filters, excl_archive_filters()} | {archive_opts, [archive_opt()]} mod() = {vsn, app_vsn()} | {incl_cond, incl_cond()} | {debug_info, debug_info()} rel_app() = app_name() | {app_name(), app_type()} | {app_name(), [incl_app()]} | {app_name(), app_type(), [incl_app()]} app_name() = atom() app_type() = permanent | transient | temporary | load | none app_vsn() = string() archive_opt = zip_create_opt() boot_rel() = rel_name() app_file() = keep | strip | all debug_info() = keep | strip dir() = string() escript() = {incl_cond, incl_cond()} escript_file() = file() excl_app_filters() = regexps() excl_archive_filters() = regexps() excl_sys_filters() = regexps() file() = string() incl_app() = app_name() incl_app_filters() = regexps() incl_archive_filters() = regexps() incl_cond() = include | exclude | derived incl_sys_filters() = regexps() lib_dir() = dir() mod_cond() = all | app | ebin | derived | none mod_name() = atom() profile() = development | embedded | standalone re_regexp() = string() reason() = string() regexps() = [re_regexp()] | {add, [re_regexp()]} | {del, [re_regexp()]} rel_file() = term() rel_name() = string() rel_vsn() = string() relocatable = boolean() root_dir() = dir() script_file() = term() server() = server_pid() | options() server_pid() = pid() target_dir() = file() window_pid() = pid()
Functions
create_target(Server, TargetDir) -> ok | {error, Reason}
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}
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}
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}
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}
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}
Server = server()
RelName = rel_name()
ScriptFile = script_file()
Reason = reason()
Get contents of a boot script file. See script(4)
for
more details.
get_server(WindowPid) -> {ok, ServerPid} | {error, Reason}
WindowPid = window_pid()
ServerPid = server_pid()
Reason = reason()
Return the process identifier of the server process.
get_target_spec(Server) -> {ok, targetSpec} | {error, Reason}
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}
Server = server()
TargetDir = target_dir()
Reason = reason()
Install a created target system
start() -> {ok, WindowPid} | {error, Reason}
WindowPid = window_pid()
Reason = reason()
Start a main window process with default options
start(Options) -> {ok, WindowPid} | {error, Reason}
Options = options()
WindowPid = window_pid()
Reason = reason()
Start a main window process with options
start_link(Options) -> {ok, WindowPid} | {error, Reason}
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}
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}
Pid = server_pid() | window_pid()()
Reason = reason()
Stop a server or window process