1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
%% -*- mode: Erlang; fill-column: 80; comment-column: 75; -*-
%% Example Relcool Config
%% ======================
%%
%% This is an example relcool config whose purpose is to demonstrate all of the
%% options available in relcool. Its not expected that you will use all of the
%% things here. In fact, there is a high likely hood that *your* relcool.config
%% will be extremely minimal, as relcool does a very good job of figuring out
%% things on its own.
%%
%% The Release We Are Building
%% ---------------------------
%%
%% Lets say we have a release called sexpr. The sexpr release supports versions
%% 0.0.1 and 0.0.2 with different dependencies. 0.0.1 requires erlware commons
%% 0.8.0 or lesser. 0.0.2 requires erlware_commons 0.8.1 or greater along with
%% neotoma (any version). We also do not want neotoma to be loaded. We also want
%% our default release. the one we build in the common case to be sexper 0.0.2.
%% You can tell relcool about additional directories that you want searched for
%% otp apps during the discovery process. You do that in the 'paths' config. You
%% can also specify these paths on the command line with `-p`. Be aware that
%% relcool plays well with rebar so if you have a deps directory in the current
%% directory it will be automatically added.
{paths, ["/opt/erlang_apps"]}.
%% If you have a sys.config file you need to tell relcool where it is. If you do
%% that relcool will include the sys.config in the appropriate place
%% automatically.
{sys_config, "./config/sys.config"}.
%% relcool will include erts by default. However, if you don't want to include
%% erts you can add the `include_erts` tuple to the config and tell relcool not
%% to include it.
{include_erts, false}.
%% When we have multiple releases relcool needs to know which one to build. You
%% can specify that on the command line with the `-n` and `-v` arguments to
%% relcool. However, it is often more convenient to do it in the config.
{default_release, sexpr, "0.0.2"}.
{release, {sexpr, "0.0.1"},
[sexpr,
%% There are two syntaxes for constraints.
%% The first is the tuple syntax shown here.
{erlware_commons, "0.8.0", '<='}]}.
{release, {sexpr, "0.0.2"},
[sexpr,
%% This is the second constraint syntax, it is interchangeable with the tuple
%% syntax and its up to you which you find more readable/usable.
"erlware_commons>=0.8.1",
%% You can put the release load types in the release spec here in exactly the
%% same way that you can do it for a normal relfile. The syntax is
%% {<constraint>, <type>}.
{neotoma, load}]}.
%% During development its often the case that you want to substitute the app
%% that you are working on for a 'production' version of an app. You can
%% explicitly tell relcool to override all versions of an app that you specify
%% with an app in an arbitrary directory. Relcool will then symlink that app
%% into the release in place of the specified app. be aware though that relcool
%% will check your app for consistancy so it should be a normal OTP app and
%% already be built.
{overrides, [{sexpr, "../sexpr"}]}.
%% In some cases you might want to add additional functionality to relcool. You
%% can do this via a 'provider'. A provider is an implementation of the relcool
%% provider behaviour. This probably shouldn't be needed very often.
{add_providers, [my_custom_functionality]}.
|
