configure_howto

Configuring the exodm system

Application dependencies

In order to add an application, two files must be modified:

• The rebar.config(see Rebar dependencies)
• The rel/rebar.config (see The release config)

Rebar dependencies

Exodm uses rebar's dependency support, with some in-house patches.

In the top-level rebar.config, the applications needed for the system are listed, e.g.:

{deps,
 [
  {unsplit, ".*", {git, "git://github.com/uwiger/unsplit.git", "HEAD"}}
  , ...
 ]}.

The way to read this is:

• The application unsplit, application version matching the regexp .* (any version), fetched from github - the latest version ("HEAD" - this could be a git tag).

Rebar will by default check the deps/ directory to see if the application is present. If so, it will read the .app file (e.g. unsplit/ebin/unsplit.app) and match the application version attribute against the above regexp, and abort if it doesn't match.

Note that each dependent app may have dependencies of its own. Rebar will honor transitive dependencies.

When in development mode, it is often convenient to have rebar find the application on your local disk. Our own patched rebar allows for a "wrapper" script (rebar.config.script) that checks for the OS environment variable $REBAR_DEPS. If present, it patches the rebar.config, using the (single) directory given by $REBAR_DEPS in place of the default deps/ dir.

In order to also generate and build the system using a patched deps directory, the same directory must also be included in the environment variable $ERL_LIBS. This env var is used by the Erlang code loader, and is given in standard Unix path syntax.

A special rebar plugin (exodm_rebar_plugin.erl) patches the configuration for Reltool so that it also knows where to find the applications.

The release config

A second rebar.config file exists for instrumenting Reltool.

The part of this config file that may need editing is the rel_apps option:

%% Add the apps that need to be included in the generated release
{rel_apps, "exodm",
	    [kernel,stdlib,sasl,runtime_tools,compiler,
	     {setup,load}, {exodm_setup, load},
	     gproc, exo, yang, bert, reactor,
	     eleveldb, sqlite3, kvdb,mnesia,unsplit,
	     {yaws,load}, exodm_http, exodm_ck3
	    ]}.

The second element is the name of the release. This will correspond to the subdirectory under rel/ where the files will be generated. The list of applications defines which applications are to be loaded and/or started in the "exodm" system. The order is semi-relevant; OTP will adjust the order if needed in order to honor application dependencies, but will otherwise keep the order intact. If an application should only be loaded, it is added as e.g. {setup, load}.