summaryrefslogtreecommitdiff
path: root/deps/setup/doc
diff options
context:
space:
mode:
authorMagnus Feuer <mfeuer@jaguarlandrover.com>2015-04-14 08:26:38 -0700
committerMagnus Feuer <mfeuer@jaguarlandrover.com>2015-04-17 14:01:27 -0700
commitb6430f5418653a2c7680217ef692613dde6f600f (patch)
tree79264d2bfd8e2d08ef62b7dd5b226b51e9574b87 /deps/setup/doc
parent682c3666ca5297157ccd76183a2d586ac72ffb69 (diff)
downloadrvi_core-b6430f5418653a2c7680217ef692613dde6f600f.tar.gz
Initial commit of deps
Diffstat (limited to 'deps/setup/doc')
-rw-r--r--deps/setup/doc/README.md109
-rw-r--r--deps/setup/doc/edoc-info4
-rw-r--r--deps/setup/doc/erlang.pngbin0 -> 2109 bytes
-rw-r--r--deps/setup/doc/overview.edoc88
-rw-r--r--deps/setup/doc/setup.md434
-rw-r--r--deps/setup/doc/setup_gen.md76
-rw-r--r--deps/setup/doc/setup_lib.md75
-rw-r--r--deps/setup/doc/stylesheet.css55
-rw-r--r--deps/setup/doc/template.conf63
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
new file mode 100644
index 0000000..987a618
--- /dev/null
+++ b/deps/setup/doc/erlang.png
Binary files differ
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() -&gt; 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()) -&gt; [{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()]) -&gt; [{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) -&gt; [{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() -&gt; [{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) -&gt; [{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) -&gt; [{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() -&gt; 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() -&gt; [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()) -&gt; [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() -&gt; 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()) -&gt; 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) -&gt; {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()) -&gt; {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) -&gt; {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) -&gt; {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() -&gt; 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) -&gt; 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) -&gt; 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) -&gt; {ok, pid()}
+</code></pre>
+<br />
+
+Application start function.
+<a name="stop-1"></a>
+
+### stop/1 ###
+
+
+<pre><code>
+stop(X1::State) -&gt; ok
+</code></pre>
+<br />
+
+Application stop function
+end
+
+<a name="verify_dir-1"></a>
+
+### verify_dir/1 ###
+
+
+<pre><code>
+verify_dir(Directory::Dir) -&gt; 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() -&gt; 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) -&gt; 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.