diff options
author | Magnus Feuer <mfeuer@jaguarlandrover.com> | 2015-04-14 08:26:38 -0700 |
---|---|---|
committer | Magnus Feuer <mfeuer@jaguarlandrover.com> | 2015-04-17 14:01:27 -0700 |
commit | b6430f5418653a2c7680217ef692613dde6f600f (patch) | |
tree | 79264d2bfd8e2d08ef62b7dd5b226b51e9574b87 /deps/setup/doc | |
parent | 682c3666ca5297157ccd76183a2d586ac72ffb69 (diff) | |
download | rvi_core-b6430f5418653a2c7680217ef692613dde6f600f.tar.gz |
Initial commit of deps
Diffstat (limited to 'deps/setup/doc')
-rw-r--r-- | deps/setup/doc/README.md | 109 | ||||
-rw-r--r-- | deps/setup/doc/edoc-info | 4 | ||||
-rw-r--r-- | deps/setup/doc/erlang.png | bin | 0 -> 2109 bytes | |||
-rw-r--r-- | deps/setup/doc/overview.edoc | 88 | ||||
-rw-r--r-- | deps/setup/doc/setup.md | 434 | ||||
-rw-r--r-- | deps/setup/doc/setup_gen.md | 76 | ||||
-rw-r--r-- | deps/setup/doc/setup_lib.md | 75 | ||||
-rw-r--r-- | deps/setup/doc/stylesheet.css | 55 | ||||
-rw-r--r-- | deps/setup/doc/template.conf | 63 |
9 files changed, 904 insertions, 0 deletions
diff --git a/deps/setup/doc/README.md b/deps/setup/doc/README.md new file mode 100644 index 0000000..305520e --- /dev/null +++ b/deps/setup/doc/README.md @@ -0,0 +1,109 @@ + + +# The setup application # + +__Authors:__ Ulf Wiger ([`ulf@wiger.net`](mailto:ulf@wiger.net)). +Generic setup utility for Erlang-based systems + + +## Introduction ## + +While Erlang/OTP comes with many wonderful applications, including the +Mnesia DBMS, there is no standard or convention for installing a +system. Erlang/OTP provides tools for building a boot script, and rules +for setting environment variables, etc., and Mnesia offers an API for +creating and modifying the database schema. + +However, with no convention for when these tools and API functions +are called - and by whom - application developers are left having to +invent a lot of code and scripts, not to mention meditate over chapters +of Erlang/OTP documentation in order to figure out how things fit +together. + +This utility offers a framework for initializing and configuring a +system, with a set of conventions allowing each component to provide +callbacks for different steps in the installation procedure. + +The callbacks are defined through OTP application environment variables, +which can easily be overriden at install time. + + +## The setup_gen utility ## + +The `setup_gen` utility is a simple tool to generate .rel file and +boot script for an Erlang-based system. It fetches configuration options +from a .conf file (read using `file:script/2`). As an example of a very +simple build, see examples/gproc.conf': + +``` + +[{apps, [kernel, + stdlib, + sasl, + gproc]}]. + +``` + +This configuration file simply lists the applications to start from the +boot script. The `setup_gen` script can either be called from within +Erlang as: + +``` + +Eshell V5.8.1 (abort with ^G) +1> setup_gen:run([{conf,"gproc.conf"},{outdir,"."},{name,"gproc"}]). +Options = [{conf,"gproc.conf"},{outdir,"."},{name,"gproc"}] +Paths = [] +add path Res = ok +app_vsn(kernel) -> "2.14.1" +app_vsn(stdlib) -> "1.17.1" +app_vsn(sasl) -> "2.1.9.2" +app_vsn(gproc) -> "0.01" +Rel: {release,{"gproc","tmp"}, + {erts,"5.8.1"}, + [{kernel,"2.14.1"}, + {stdlib,"1.17.1"}, + {sasl,"2.1.9.2"}, + {gproc,"0.01"}]} +entering directory . +Path = [] +make_script() -> ok +ok + +``` + +...or as an escript: + +``` + +escript ~/git/setup/ebin/setup_gen.beam gproc gproc.conf . + +``` + +If the option `-install true` is given, the `setup_gen` utility will +generate an installation boot script, and `install.config` file, which +can be used to install the system, using a command like: + +``` + +erl -sys install -boot install + +``` + +This boot script will run kernel, stdlib and sasl, then load all other +applications, and finally run the `setup` application, which will find +and execute any setup hooks. +If the option `-setup stop_when_done true` is added to the command line, +the setup application will automatically shut down all running nodes after +running the setup hooks. Otherwise (default), it will hand over control to +the shell rather than terminate the Erlang VM. + + +## Modules ## + + +<table width="100%" border="0" summary="list of modules"> +<tr><td><a href="setup.md" class="module">setup</a></td></tr> +<tr><td><a href="setup_gen.md" class="module">setup_gen</a></td></tr> +<tr><td><a href="setup_lib.md" class="module">setup_lib</a></td></tr></table> + diff --git a/deps/setup/doc/edoc-info b/deps/setup/doc/edoc-info new file mode 100644 index 0000000..45fac83 --- /dev/null +++ b/deps/setup/doc/edoc-info @@ -0,0 +1,4 @@ +%% encoding: UTF-8 +{application,setup}. +{packages,[]}. +{modules,[setup,setup_gen,setup_lib]}. diff --git a/deps/setup/doc/erlang.png b/deps/setup/doc/erlang.png Binary files differnew file mode 100644 index 0000000..987a618 --- /dev/null +++ b/deps/setup/doc/erlang.png diff --git a/deps/setup/doc/overview.edoc b/deps/setup/doc/overview.edoc new file mode 100644 index 0000000..2fc993e --- /dev/null +++ b/deps/setup/doc/overview.edoc @@ -0,0 +1,88 @@ +@author Ulf Wiger <ulf@wiger.net> + +@doc Generic setup utility for Erlang-based systems +<h2>Introduction</h2> + +While Erlang/OTP comes with many wonderful applications, including the +Mnesia DBMS, there is no standard or convention for installing a +system. Erlang/OTP provides tools for building a boot script, and rules +for setting environment variables, etc., and Mnesia offers an API for +creating and modifying the database schema. + +However, with no convention for when these tools and API functions +are called - and by whom - application developers are left having to +invent a lot of code and scripts, not to mention meditate over chapters +of Erlang/OTP documentation in order to figure out how things fit +together. + +This utility offers a framework for initializing and configuring a +system, with a set of conventions allowing each component to provide +callbacks for different steps in the installation procedure. + +The callbacks are defined through OTP application environment variables, +which can easily be overriden at install time. + +<h2>The setup_gen utility</h2> + +The `setup_gen' utility is a simple tool to generate .rel file and +boot script for an Erlang-based system. It fetches configuration options +from a .conf file (read using `file:script/2'). As an example of a very +simple build, see examples/gproc.conf': + +<pre> +[{apps, [kernel, + stdlib, + sasl, + gproc]}]. +</pre> + +This configuration file simply lists the applications to start from the +boot script. The `setup_gen' script can either be called from within +Erlang as: + +<pre> +Eshell V5.8.1 (abort with ^G) +1> setup_gen:run([{conf,"gproc.conf"},{outdir,"."},{name,"gproc"}]). +Options = [{conf,"gproc.conf"},{outdir,"."},{name,"gproc"}] +Paths = [] +add path Res = ok +app_vsn(kernel) -> "2.14.1" +app_vsn(stdlib) -> "1.17.1" +app_vsn(sasl) -> "2.1.9.2" +app_vsn(gproc) -> "0.01" +Rel: {release,{"gproc","tmp"}, + {erts,"5.8.1"}, + [{kernel,"2.14.1"}, + {stdlib,"1.17.1"}, + {sasl,"2.1.9.2"}, + {gproc,"0.01"}]} +entering directory . +Path = [] +make_script() -> ok +ok +</pre> + +...or as an escript: + +<pre> +escript ~/git/setup/ebin/setup_gen.beam gproc gproc.conf . +</pre> + +If the option `-install true' is given, the `setup_gen' utility will +generate an installation boot script, and `install.config' file, which +can be used to install the system, using a command like: + +<pre> +erl -sys install -boot install +</pre> + +This boot script will run kernel, stdlib and sasl, then load all other +applications, and finally run the `setup' application, which will find +and execute any setup hooks. + +If the option `-setup stop_when_done true' is added to the command line, +the setup application will automatically shut down all running nodes after +running the setup hooks. Otherwise (default), it will hand over control to +the shell rather than terminate the Erlang VM. + +@end
\ No newline at end of file diff --git a/deps/setup/doc/setup.md b/deps/setup/doc/setup.md new file mode 100644 index 0000000..df22af0 --- /dev/null +++ b/deps/setup/doc/setup.md @@ -0,0 +1,434 @@ + + +# Module setup # +* [Description](#description) +* [Function Index](#index) +* [Function Details](#functions) + + +Setup utility for erlang applications. +__Behaviours:__ [`application`](application.md). +<a name="index"></a> + +## Function Index ## + + +<table width="100%" border="1" cellspacing="0" cellpadding="2" summary="function index"><tr><td valign="top"><a href="#data_dir-0">data_dir/0</a></td><td>Returns the configured data dir, or a best guess (<code>home()/data.Node</code>).</td></tr><tr><td valign="top"><a href="#expand_value-2">expand_value/2</a></td><td></td></tr><tr><td valign="top"><a href="#find_app-1">find_app/1</a></td><td>Equivalent to <a href="#find_app-2"><tt>find_app(A, lib_dirs())</tt></a>.</td></tr><tr><td valign="top"><a href="#find_app-2">find_app/2</a></td><td>Locates application <code>A</code> along LibDirs (see <a href="#lib_dirs-0"><code>lib_dirs/0</code></a> and +<a href="#lib_dirs-1"><code>lib_dirs/1</code></a>) or under the OTP root, returning all found candidates.</td></tr><tr><td valign="top"><a href="#find_env_vars-1">find_env_vars/1</a></td><td>Searches all loaded apps for instances of the <code>Env</code> environment variable.</td></tr><tr><td valign="top"><a href="#find_hooks-0">find_hooks/0</a></td><td>Finds all custom setup hooks in all applications.</td></tr><tr><td valign="top"><a href="#find_hooks-1">find_hooks/1</a></td><td>Find all setup hooks for <code>Mode</code> in all applications.</td></tr><tr><td valign="top"><a href="#find_hooks-2">find_hooks/2</a></td><td>Find all setup hooks for <code>Mode</code> in <code>Applications</code>.</td></tr><tr><td valign="top"><a href="#get_env-2">get_env/2</a></td><td></td></tr><tr><td valign="top"><a href="#home-0">home/0</a></td><td>Returns the configured <code>home</code> directory, or a best guess (<code>$CWD</code>).</td></tr><tr><td valign="top"><a href="#lib_dirs-0">lib_dirs/0</a></td><td>Equivalent to <a href="#lib_dirs-1"><tt>lib_dirs(concat("ERL_SETUP_LIBS", "ERL_LIBS"))</tt></a>.</td></tr><tr><td valign="top"><a href="#lib_dirs-1">lib_dirs/1</a></td><td>Returns an expanded list of application directories under a lib path.</td></tr><tr><td valign="top"><a href="#log_dir-0">log_dir/0</a></td><td>Returns the configured log dir, or a best guess (<code>home()/log.Node</code>).</td></tr><tr><td valign="top"><a href="#ok-1">ok/1</a></td><td></td></tr><tr><td valign="top"><a href="#patch_app-1">patch_app/1</a></td><td>Adds an application's "development" path to a target system.</td></tr><tr><td valign="top"><a href="#pick_vsn-3">pick_vsn/3</a></td><td>Picks the specified version out of a list returned by <a href="#find_app-1"><code>find_app/1</code></a></td></tr><tr><td valign="top"><a href="#read_config_script-3">read_config_script/3</a></td><td></td></tr><tr><td valign="top"><a href="#reload_app-1">reload_app/1</a></td><td>Equivalent to <a href="#reload_app-2"><tt>reload_app(AppName, latest)</tt></a>.</td></tr><tr><td valign="top"><a href="#reload_app-2">reload_app/2</a></td><td>Equivalent to <a href="#reload_app-3"><tt>reload_app(AppName, latest, lib_dirs())</tt></a>.</td></tr><tr><td valign="top"><a href="#reload_app-3">reload_app/3</a></td><td>Loads or upgrades an application to the specified version.</td></tr><tr><td valign="top"><a href="#run_hooks-0">run_hooks/0</a></td><td>Execute all setup hooks for current mode in order.</td></tr><tr><td valign="top"><a href="#run_hooks-1">run_hooks/1</a></td><td>Execute setup hooks for current mode in <code>Applications</code> in order.</td></tr><tr><td valign="top"><a href="#run_hooks-2">run_hooks/2</a></td><td>Execute setup hooks for <code>Mode</code> in <code>Applications</code> in order.</td></tr><tr><td valign="top"><a href="#start-2">start/2</a></td><td>Application start function.</td></tr><tr><td valign="top"><a href="#stop-1">stop/1</a></td><td>Application stop function +end.</td></tr><tr><td valign="top"><a href="#verify_dir-1">verify_dir/1</a></td><td>Ensures that the directory Dir exists and is writable.</td></tr><tr><td valign="top"><a href="#verify_directories-0">verify_directories/0</a></td><td>Ensures that essential directories exist and are writable.</td></tr></table> + + +<a name="functions"></a> + +## Function Details ## + +<a name="data_dir-0"></a> + +### data_dir/0 ### + + +<pre><code> +data_dir() -> Directory +</code></pre> +<br /> + +Returns the configured data dir, or a best guess (`home()/data.Node`). + +<a name="expand_value-2"></a> + +### expand_value/2 ### + +`expand_value(App, Value) -> any()` + + +<a name="find_app-1"></a> + +### find_app/1 ### + + +<pre><code> +find_app(A::atom()) -> [{Vsn, Dir}] +</code></pre> +<br /> + +Equivalent to [`find_app(A, lib_dirs())`](#find_app-2). +<a name="find_app-2"></a> + +### find_app/2 ### + + +<pre><code> +find_app(A::atom(), LibDirs::[string()]) -> [{Vsn, Dir}] +</code></pre> +<br /> + +Locates application `A` along LibDirs (see [`lib_dirs/0`](#lib_dirs-0) and +[`lib_dirs/1`](#lib_dirs-1)) or under the OTP root, returning all found candidates. +The version is extracted from the `.app` file; thus, no version suffix +in the path name is required. +<a name="find_env_vars-1"></a> + +### find_env_vars/1 ### + + +<pre><code> +find_env_vars(Env) -> [{AppName, Value}] +</code></pre> +<br /> + + +Searches all loaded apps for instances of the `Env` environment variable. + + +The environment variables may contain instances of +`$APP`, `$PRIV_DIR`, `$LIB_DIR`, `$DATA_DIR`, `$LOG_DIR`, `$HOME`, +inside strings or binaries, and these will be replaced with actual values +for the current system (`$APP` simply expands to the name of the current +application). +<a name="find_hooks-0"></a> + +### find_hooks/0 ### + + +<pre><code> +find_hooks() -> [{PhaseNo, [{M, F, A}]}] +</code></pre> +<br /> + +Finds all custom setup hooks in all applications. +The setup hooks must be of the form + +``` +{'$setup_hooks', [{PhaseNo, {M, F, A}}]} +``` + +, +where PhaseNo should be (but doesn't have to be) an integer. + + + +The hooks will be called in order: +- The phase numbers will be sorted. +- All hooks for a specific PhaseNo will be called in sequence, +in the same order as the applications appear in the boot script +(and, if included applications exist, in preorder traversal order). + + +A suggested convention is: +- Create the database at phase 100 +- Create tables (or configure schema) at 200 +- Populate the database at 300 +<a name="find_hooks-1"></a> + +### find_hooks/1 ### + + +<pre><code> +find_hooks(Mode) -> [{PhaseNo, [{M, F, A}]}] +</code></pre> +<br /> + +Find all setup hooks for `Mode` in all applications +<a name="find_hooks-2"></a> + +### find_hooks/2 ### + + +<pre><code> +find_hooks(Mode, Applications) -> [{PhaseNo, [{M, F, A}]}] +</code></pre> +<br /> + +Find all setup hooks for `Mode` in `Applications`. +<a name="get_env-2"></a> + +### get_env/2 ### + +`get_env(A, Key) -> any()` + + +<a name="home-0"></a> + +### home/0 ### + + +<pre><code> +home() -> Directory +</code></pre> +<br /> + +Returns the configured `home` directory, or a best guess (`$CWD`) +<a name="lib_dirs-0"></a> + +### lib_dirs/0 ### + + +<pre><code> +lib_dirs() -> [string()] +</code></pre> +<br /> + +Equivalent to [`lib_dirs(concat("ERL_SETUP_LIBS", "ERL_LIBS"))`](#lib_dirs-1). +<a name="lib_dirs-1"></a> + +### lib_dirs/1 ### + + +<pre><code> +lib_dirs(Env::string()) -> [string()] +</code></pre> +<br /> + + +Returns an expanded list of application directories under a lib path + + +This function expands the (ebin/) directories under e.g. `$ERL_SETUP_LIBS` or +`$ERL_LIBS`. `$ERL_SETUP_LIB` has the same syntax and semantics as +`$ERL_LIBS`, but is (hopefully) only recognized by the `setup` application. +This can be useful e.g. when keeping a special 'extensions' or 'plugin' +root that is handled via `setup`, but not treated as part of the normal +'automatic code loading path'. +<a name="log_dir-0"></a> + +### log_dir/0 ### + + +<pre><code> +log_dir() -> Directory +</code></pre> +<br /> + +Returns the configured log dir, or a best guess (`home()/log.Node`) +<a name="ok-1"></a> + +### ok/1 ### + +`ok(Other) -> any()` + + +<a name="patch_app-1"></a> + +### patch_app/1 ### + + +<pre><code> +patch_app(AppName::atom()) -> true | {error, Reason} +</code></pre> +<br /> + + +Adds an application's "development" path to a target system + + + +This function locates the given application (`AppName`) along the `$ERL_LIBS` +path, and prepends it to the code path of the existing system. This is useful +not least when one wants to add e.g. a debugging or trace application to a +target system. + + +The function will not add the same path again, if the new path is already +the 'first' path entry for the application `A`. +<a name="pick_vsn-3"></a> + +### pick_vsn/3 ### + + +<pre><code> +pick_vsn(App::atom(), Dirs::[{Vsn::string(), Dir::string()}], Vsn::Which) -> {Vsn, Dir} +</code></pre> + +<ul class="definitions"><li><code>Which = latest | next | Regexp</code></li></ul> + + +Picks the specified version out of a list returned by [`find_app/1`](#find_app-1) + + + +* If `Which` is a string, it will be used as a `re` regexp pattern, and the +first matching version will be returned. + + + +* If `Which = latest`, the last entry in the list will be returned (assumes +that the list is sorted in ascending version order). + + + +* If `Which = next`, the next version following the current version of the +application `A` is returned, assuming `A` is loaded; if `A` is not loaded, +the first entry in the list is returned. + + +If no matching version is found, the function raises an exception. +<a name="read_config_script-3"></a> + +### read_config_script/3 ### + +`read_config_script(F, Name, Opts) -> any()` + + +<a name="reload_app-1"></a> + +### reload_app/1 ### + + +<pre><code> +reload_app(AppName::atom()) -> {ok, NotPurged} | {error, Reason} +</code></pre> +<br /> + +Equivalent to [`reload_app(AppName, latest)`](#reload_app-2). +<a name="reload_app-2"></a> + +### reload_app/2 ### + + +<pre><code> +reload_app(AppName::atom(), ToVsn) -> {ok, UnPurged} | {error, Reason} +</code></pre> +<br /> + +Equivalent to [`reload_app(AppName, latest, lib_dirs())`](#reload_app-3). +<a name="reload_app-3"></a> + +### reload_app/3 ### + + +<pre><code> +reload_app(AppName::atom(), ToVsn0::ToVsn, LibDirs) -> {ok, Unpurged} | {error, Reason} +</code></pre> + +<ul class="definitions"><li><code>ToVsn = latest | next | Vsn</code></li><li><code>LibDirs = [string()]</code></li><li><code>Vsn = string()</code></li></ul> + + +Loads or upgrades an application to the specified version + + + +This function is a convenient function for 'upgrading' an application. +It locates the given version (using [`find_app/1`](#find_app-1) and [`pick_vsn/3`](#pick_vsn-3)) +and loads it in the most appropriate way: + + + +* If the application isn't already loaded, it loads the application and +all its modules. + + + +* If the application is loaded, it generates an appup script and performs +a soft upgrade. If the new version of the application has an `.appup` script +on-disk, that script is used instead. + + + +The application is searched for along the existing path (that is, under +the roots of the existing code path, allowing for e.g. $ROOT/lib/app-1.0 +and $ROOT/lib/app-1.2 to be found and tested against the version condition), +and also along `LibDirs` (see [`lib_dirs/0`](#lib_dirs-0) an [`lib_dirs/1`](#lib_dirs-1)). + + + +The generated appup script is of the form: + + + +* add modules not present in the previous version of the application + + + +* do a soft upgrade on pre-existing modules, using suspend-code_change-resume + + + +* delete modules that existed in the old version, but not in the new. + + + +The purge method used is `brutal_purge` - see [`//sasl/appup`](/Users/uwiger/uw/me/sasl/doc/appup.md). + + +For details on how the new version is chosen, see [`find_app/1`](#find_app-1) and +[`pick_vsn/3`](#pick_vsn-3). +<a name="run_hooks-0"></a> + +### run_hooks/0 ### + + +<pre><code> +run_hooks() -> ok +</code></pre> +<br /> + +Execute all setup hooks for current mode in order. +<a name="run_hooks-1"></a> + +### run_hooks/1 ### + + +<pre><code> +run_hooks(Apps::Applications) -> ok +</code></pre> +<br /> + +Execute setup hooks for current mode in `Applications` in order. +<a name="run_hooks-2"></a> + +### run_hooks/2 ### + + +<pre><code> +run_hooks(Mode, Apps::Applications) -> ok +</code></pre> +<br /> + +Execute setup hooks for `Mode` in `Applications` in order +<a name="start-2"></a> + +### start/2 ### + + +<pre><code> +start(X1::Type, Args) -> {ok, pid()} +</code></pre> +<br /> + +Application start function. +<a name="stop-1"></a> + +### stop/1 ### + + +<pre><code> +stop(X1::State) -> ok +</code></pre> +<br /> + +Application stop function +end + +<a name="verify_dir-1"></a> + +### verify_dir/1 ### + + +<pre><code> +verify_dir(Directory::Dir) -> Dir +</code></pre> +<br /> + +Ensures that the directory Dir exists and is writable. +<a name="verify_directories-0"></a> + +### verify_directories/0 ### + + +<pre><code> +verify_directories() -> ok +</code></pre> +<br /> + +Ensures that essential directories exist and are writable. +Currently, only the log directory is verified. diff --git a/deps/setup/doc/setup_gen.md b/deps/setup/doc/setup_gen.md new file mode 100644 index 0000000..75762d3 --- /dev/null +++ b/deps/setup/doc/setup_gen.md @@ -0,0 +1,76 @@ + + +# Module setup_gen # +* [Function Index](#index) +* [Function Details](#functions) + + +<a name="index"></a> + +## Function Index ## + + +<table width="100%" border="1" cellspacing="0" cellpadding="2" summary="function index"><tr><td valign="top"><a href="#help-0">help/0</a></td><td></td></tr><tr><td valign="top"><a href="#main-1">main/1</a></td><td></td></tr><tr><td valign="top"><a href="#run-1">run/1</a></td><td>Generates .rel file(s) and boot scripts for a given configuration.</td></tr></table> + + +<a name="functions"></a> + +## Function Details ## + +<a name="help-0"></a> + +### help/0 ### + +`help() -> any()` + + +<a name="main-1"></a> + +### main/1 ### + +`main(Args) -> any()` + + +<a name="run-1"></a> + +### run/1 ### + + +<pre><code> +run(Options) -> ok +</code></pre> +<br /> + + +Generates .rel file(s) and boot scripts for a given configuration. + + + +This function reads a configuration specification and generates the +files needed to start a node from an OTP boot script. Optionally, it can +also generate a 'setup' script, which contains the same applications, but +only loaded (except the `setup` application, if present, which is started). +This way, a node can be started with all paths set, and all environment +variables defined, such that a database can be created, and other setup +tasks be performed. + + + +Mandatory options: +* `{name, Name}` - Name of the release (and of the .rel and .script files) +* `{outdir, Dir}` - Where to put the generated files. Dir is created if not +already present. +* `{conf, Conf}` - Config file listing apps and perhaps other options + + +Additional options: +* `{apps, [App]}` - List of applications to include in the release. Only the +first instance of this option is considered. +* `{add_apps, [App]}` - Adds applications to the ones given in the `apps` +option. +* `{include, ConfigFile}` - include options from the given file. The file +is processed using `file:script/2`. +* `{include_lib, ConfigFile}` - As above, but ConfigFile is named as with +the `-include_lib(...)` directive in Erlang +source code. +* ... diff --git a/deps/setup/doc/setup_lib.md b/deps/setup/doc/setup_lib.md new file mode 100644 index 0000000..cea9d44 --- /dev/null +++ b/deps/setup/doc/setup_lib.md @@ -0,0 +1,75 @@ + + +# Module setup_lib # +* [Function Index](#index) +* [Function Details](#functions) + + +<a name="index"></a> + +## Function Index ## + + +<table width="100%" border="1" cellspacing="0" cellpadding="2" summary="function index"><tr><td valign="top"><a href="#abort-2">abort/2</a></td><td></td></tr><tr><td valign="top"><a href="#compare_vsns-2">compare_vsns/2</a></td><td></td></tr><tr><td valign="top"><a href="#help-0">help/0</a></td><td></td></tr><tr><td valign="top"><a href="#is_string-1">is_string/1</a></td><td></td></tr><tr><td valign="top"><a href="#releases_dir-0">releases_dir/0</a></td><td></td></tr><tr><td valign="top"><a href="#sort_vsns-2">sort_vsns/2</a></td><td></td></tr><tr><td valign="top"><a href="#write_eterm-2">write_eterm/2</a></td><td></td></tr><tr><td valign="top"><a href="#write_script-2">write_script/2</a></td><td></td></tr></table> + + +<a name="functions"></a> + +## Function Details ## + +<a name="abort-2"></a> + +### abort/2 ### + +`abort(Fmt, Args) -> any()` + + +<a name="compare_vsns-2"></a> + +### compare_vsns/2 ### + +`compare_vsns(V1, V2) -> any()` + + +<a name="help-0"></a> + +### help/0 ### + +`help() -> any()` + + +<a name="is_string-1"></a> + +### is_string/1 ### + +`is_string(L) -> any()` + + +<a name="releases_dir-0"></a> + +### releases_dir/0 ### + +`releases_dir() -> any()` + + +<a name="sort_vsns-2"></a> + +### sort_vsns/2 ### + +`sort_vsns(Dirs, AppStr) -> any()` + + +<a name="write_eterm-2"></a> + +### write_eterm/2 ### + +`write_eterm(F, Term) -> any()` + + +<a name="write_script-2"></a> + +### write_script/2 ### + +`write_script(F, Script) -> any()` + + diff --git a/deps/setup/doc/stylesheet.css b/deps/setup/doc/stylesheet.css new file mode 100644 index 0000000..e426a90 --- /dev/null +++ b/deps/setup/doc/stylesheet.css @@ -0,0 +1,55 @@ +/* standard EDoc style sheet */ +body { + font-family: Verdana, Arial, Helvetica, sans-serif; + margin-left: .25in; + margin-right: .2in; + margin-top: 0.2in; + margin-bottom: 0.2in; + color: #000000; + background-color: #ffffff; +} +h1,h2 { + margin-left: -0.2in; +} +div.navbar { + background-color: #add8e6; + padding: 0.2em; +} +h2.indextitle { + padding: 0.4em; + background-color: #add8e6; +} +h3.function,h3.typedecl { + background-color: #add8e6; + padding-left: 1em; +} +div.spec { + margin-left: 2em; + background-color: #eeeeee; +} +a.module,a.package { + text-decoration:none +} +a.module:hover,a.package:hover { + background-color: #eeeeee; +} +ul.definitions { + list-style-type: none; +} +ul.index { + list-style-type: none; + background-color: #eeeeee; +} + +/* + * Minor style tweaks + */ +ul { + list-style-type: square; +} +table { + border-collapse: collapse; +} +td { + padding: 3 +} diff --git a/deps/setup/doc/template.conf b/deps/setup/doc/template.conf new file mode 100644 index 0000000..a264e4f --- /dev/null +++ b/deps/setup/doc/template.conf @@ -0,0 +1,63 @@ +%% -*- erlang -*- +%%============================================================================== +%% Copyright 2014 Ulf Wiger +%% +%% Licensed under the Apache License, Version 2.0 (the "License"); +%% you may not use this file except in compliance with the License. +%% You may obtain a copy of the License at +%% +%% http://www.apache.org/licenses/LICENSE-2.0 +%% +%% Unless required by applicable law or agreed to in writing, software +%% distributed under the License is distributed on an "AS IS" BASIS, +%% WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +%% See the License for the specific language governing permissions and +%% limitations under the License. +%%============================================================================== +%% config template +%% @author ulf@wiger.net + + +%% This file is read using file:script/2 with the following +%% variable bindings: +%% Name Name of release +%% CWD Current working directory</td></tr> +%% Options List of options (proplist) given to setup_gen +%% +%% The file shold contain Erlang expressions, each terminated with +%% a period and newline. The result of the last expression must be +%% a list of {Key, Value} tuples. +%% +%% It is possible to add custom config values (todo: how to make these +%% available?). Predefined config values are: +%% - {apps, [App]} +%% App = AppName :: atom() +%% | {AppName, Type} +%% | {AppName, Incls}p +%% | {AppName, Type, Incls} +%% - {nodes, [NodeName]} +%% The names of the nodes that should be started +%% - {env, [{AppName, [{Key, Value}]}]} +%% Add or modify application environment variables. If the given +%% variables exist, they will be shadowed. Successive env items can +%% correspondingly shadow those given in previous env entries. +%% The order of defining env variables is as follows: +%% 1. Statically defined variables in the .app files +%% 2. variables defined in releases/Vsn/Relname.config +%% 3. env items in a target config like this one +%% These are added to the Relname.config and written to +%% releases/Vsn/sys.config +%% 4. Env variables added to the command line when starting erlang. +%% - {target_subdir, SubDir} +%% Make all generated files appear in TargetDir/SubDir, rather than in +%% TargetDir (argument given to make_scripts). The subdirectory will be +%% created automatically. +%% +%% Example: +%% {ok, Host} = inet:gethostname(). +%% Nodes = [list_to_atom(Name) ++ "@" ++ Host || Name <- [n1, n2]]. +%% {ok, Base}= file:script("base.conf"). +%% %% return the config +%% [ +%% {nodes, Nodes} +%% ] ++ Base. |