Fork me on GitHub

rebar3_document6

发表于 | 分类于

[TOC]

#Releases
Releases shouldn’t be a pain to build and run – especially since you have all the necessary pieces sitting right there! – and we’ve done our best to make that no longer the case.

What are releases and target systems anyway?

A release is the set of applications needed for booting an Erlang VM and starting your project. This is described through a release resource file (.rel) which is used to generate a .script and .boot. The boot file is the binary form of the script file and is what is used by the Erlang Run Time System (ERTS) to start an Erlang node, sort of like booting an operating system. Even running erl on the command line is using a boot script.
A target system is an Erlang system capable of being booted on another machine (virtual or otherwise), often ERTS is bundled along with the target system.
For more information checkout the chapter on releases (though it relies on reltool) from Learn You Some Erlang.

Reltool is out and relx is in. If you want to continue using reltool you can manually, it is still bundled with Erlang/OTP.

##Getting Started
Add a relx section to your project’s rebar.config:

1
2
3
4
5
6
7
{relx, [{release, {<release name>, <vsn>},
         [<app>]},

        {dev_mode, true},
        {include_erts, false},

        {extended_start_script, true}]}.

Running rebar3 release will build the release and provide a script for starting a node under _build/<profile>/rel/<release name>/bin/<release name>.

<release_name> must be an atom, same for each <app> in the list of applications to include in the release.

<vsn> can be one of:

Version type Result
string() A string is used as is for the version. Example: `”0.1.0”
semver Uses the latest git tag on the repo to construct the version.
{cmd, string()} Uses the result of executing the contents of string() in a shell. Example to use a file VERSION: {cmd, “cat VERSION tr -d ‘[:space:]’”}

You can add multiple release sections to your project’s rebar.config under relx.
You can either just specify different releases sharing the same configuration:

1
2
3
4
5
6
7
8
9
{relx, [{release, {<release name>, "0.0.1"},
         [<app>]},
        {release, {<release name>, "0.1.0"},
         [<app>]},

        {dev_mode, true},
        {include_erts, false},

        {extended_start_script, true}]}.

Or you can also specify releases with independent configurations:

1
2
3
4
5
6
7
8
{relx, [{release, {<release name>, "0.0.1"},
         [<app>],
         [{dev_mode, false},
          {include_erts, true}]},
        {release, {<release name>, "0.1.0"},
         [<app>],
         [{dev_mode, true}]}
       ]}.

You can build specific releases using rebar3 release -n <release_name>

##Developing
While developing you’ll likely want all your changes to applications be immediately available in the release. relx provides dev_mode for this. Instead of copying the applications that make up the release to the release structure it creates symlinks, so compiling and restarting or loading the changed modules, is all that is necessary.

1
2
3
4
5
{relx, [...
        {dev_mode, true},
        ...
       ]
}.

##Configuration
By default relx will give a basic vm.args file that sets a node name and cookie. For a complete list of options and their use check the Erlang documentation.

1
2
3
4
5
## Name of the node
-name {{release_name}}@127.0.0.1

## Cookie for distributed erlang
-setcookie {{release_name}}

To provide a custom vm.args, usually placed in the config/ directory at the root of your project, add this line to the relx section of your rebar.config:

1
{vm_args, "config/vm.args"}

##Application Configuration
For passing application environment variables there is sys.config:

1
2
3
[
  {<app_name>, [...]}
].

The default sys.config is empty, so use your own simply add it to your relx section of rebar.config:

1
{sys_config, "config/sys.config"}

##Dynamic Configuration
With OTP-21+ and rebar3 3.6+

Starting with Erlang/OTP 21 and rebar3 3.6.0 the configuration options sys_config_src and vm_args_src are available for explicitly including templates that will be rendered at runtime.

1
2
3
[
  {appname, [{port, ${PORT}}]}
].
1
-name ${NODE_NAME}
1
2
3
4
5
6
7
8
9
10
{relx, [{release, {<release name>, "0.0.1"},
         [<app>]},

        {dev_mode, true},
        {include_erts, false},

	      {sys_config_src, "config/sys.config.src"},
        {vm_args_src, "config/vm.args.src"},

        {extended_start_script, true}]}.

Note that, unlike previous versions, if you use the _src variants you do not have to set RELX_REPLACE_OS_VARS in order for the start script to do the replacement, this will happen automatically if the .src files are present in the release.

Before OTP-21 and rebar3 3.6

By setting RELX_REPLACE_OS_VARS=true both vm.args and sys.config files may contain OS environment variables that will be replaced with the current value from the environment the node is started in. This means a vm.args and sys.config for a release that starts a web server listening on a port could look like:

1
-name ${NODE_NAME}
1
2
3
[
 {appname, [{port, "${PORT}"}]}
].

And then be used to start multiple nodes of the same release with different name.

1
2
3
4
5
6
7
8
9
#!/bin/bash

export RELX_REPLACE_OS_VARS=true

for i in `seq 1 10`;
do
    NODE_NAME=node_$i PORT=808$i _build/default/rel/<release>/bin/<release> foreground &
    sleep 1
done

Overlays

Overlays provide the ability to define files and templates to include in the target system. For example, custom scripts for managing your node or the Procfile needed for running on Heroku.

1
2
3
4
5
6
7
{relx, [
    ...
    {overlay_vars, "vars.config"},
    {overlay, [{mkdir, "log/sasl"},
               {template, "priv/app.config", "etc/app.config"},
               {copy, "Procfile", "Procfile"}]}
]}.

The supported actions are:

  1. mkdir to create a directory within the release
  2. copy to copy a file from a local directory to a location within the release
  3. template to behave the way copy does, but with variable expansion in it.

Relx’s templating exposes variables along with the full power of a Mustache templating system (see mustache). You can look at the documentation there for the full syntax supported.

There is a set of variables made available by default which are described in the next session, and custom variables can otherwise be declared in the file specified in {overlay_vars, “vars.config”}, which should have the following format:

1
2
3
4
5
%% some variables
{key, value}.
{other_key, other_val}.
%% includes variables from another file
"./some_file.config".

The default variables are defined below.

Predefined variables

  1. log : The current log level in the format of (<logname>:<loglevel>)
  2. output_dir : The current output directory for the built release
  3. target_dir : The same as output_dir, exists for backwards compatibility
  4. overridden : The current list of overridden apps (a list of app names)
  5. goals : The list of user specified goals in the system
  6. lib_dirs : The list of library directories, both user specified and derived
  7. config_file : The list of config file used in the system
  8. providers : The list of provider names used for this run of relx
  9. sys_config : The location of the sys config file
  10. root_dir : The root dir of the current project
  11. default_release_name : The current default release name for the relx run
  12. default_release_version : The current default release version for the relx run
  13. default_release : The current default release for the relx run
  14. release_erts_version : The version of the Erlang Runtime System in use
  15. erts_vsn : The same as release_erts_version (for backwards compatibility)
  16. release_name : The currently executing release
  17. release_version : the currently executing version
  18. rel_vsn : Same as release_version. Exists for backwards compatibility
  19. release_applications : A list of applications included in the release

Splitting configurations

It is possible to split overlay files to deal with more complex situations. To explain this lets look at the a simplified example:

We build our application and want to distinguish between production and developing builds by having the overlay variable build spell out either “prod” or “dev” so the app.config file could include it in it’s configuration and we can either enable or disable features.

For this we build three overlay files:

  1. a dev.config - that is dev branch specific
  2. a prod.config - that is prod branch specific
  3. a base.config - that is not branch specific

For dev builds we will use dev.config as overlay_vars and for prod we will be using prod.config.

1
2
3
4
%%base.config
{data_dir, "/data/yolo_app"}.
{version, "1.0.0"}.
{run_user, "root"}.

1
2
3
4
5
%%dev.config
%% Include the base config
"./base.config".
%% The build we have
{build, "dev"}.
1
2
3
4
5
%%prod.config
%% Include the base config
"./base.config".
%% The build we have
{build, "prod"}.

##Deployable
To build a release capable of being copied to other nodes we must turn off dev_mode so applications are copied to the release lib dir instead of being symlinks.
$ rebar3 release -d false
Or create a profile that turns off dev_mode:
{profiles, [{prod, [{relx, [{dev_mode, false}]}]}]}.

Target System
A target system can not have symlinks like those created when using dev_mode and often we want to include ERTS along with the system so it does not need to be previously installed on the target.

1
2
3
4
5
{profiles, [{prod, [{relx, [{dev_mode, false}
                           ,{include_erts, true}]}]}]}.
```    

Now we can also build a compressed archive to copy to the target:

$ rebar3 as prod tar
===> Verifying default dependencies…
===> Compiling myrel
===> Starting relx build process …
===> Resolving OTP Applications from directories:
…/myrel/apps
/usr/lib/erlang/lib
===> Resolved myrel-0.1.0
===> Including Erts from /usr/lib/erlang
===> release successfully created!
===> tarball …/myrel/_build/rel/myrel/myrel-0.1.0.tar.gz successfully created!

1
Now a tarball myrel-0.1.0.tar.gz can be copied to another compatible system and booted:

$ mkdir myrel
$ mv myrel-0.1.0.tar.gz myrel/
$ cd myrel
$ tar -zxvf myrel-0.1.0.tar.gz
$ bin/myrel console

1
2
3
4

**Without Erts**

To use the ERTS and base applications like kernel and stdlib on the target, set include_erts and system_libs to false in the relx configuration tuple:

{include_erts, false},
{system_libs, false},
…

1
2
3
4
5
6
7
8
9
10
11

##Source Code Inclusion in Release
By default the release will include source files of your applications, if present.
If you don't want to include the source files, set include_src to false.
`{include_src, false}`

##Application exclusions
The following allows you to remove specific applications from the output release.
`{exclude_apps, [app1, app2]}`
##Module exclusions
The following directive allows you to remove application modules from the output release.

{exclude_modules, [
{app1, [app1_mod1, app1_mod2]},
{app2, [app2_mod1, app2_mod2]}
]}.

1
2
##Cross Compiling
If you wish to include an Erlang Run Time System that is not the version you are using to run rebar3, for example you are building on MacOSX but wish to include an ERTS that was built for a version of GNU/Linux, you can supply a path instead of a boolean for include_erts and provide a path for system_libs, still within the relx configuration tuple:

{include_erts, “/path/to/erlang”},
{system_libs, “/path/to/erlang”},
…

1
2
3
4
5
6
7
8
9
10
11
Using these paths with profiles can yield easier ways to set up cross-compiling.

##Hooks
It is possible to define hooks on specific operations of the extended start script, the operations are start, stop, install_upgrade, pre and post hooks for each of these operations are available.

The hooks can either be builtin (ie. they are already included in the release) or custom (scripts written by the user for custom functionality), the builtin scripts offer pre-packaged functionality, they are:


1. pid : Writes the beam pid to a configurable file location(/var/run/<rel_name>.pid by default).
2. wait_for_vm_start : Waits for the vm to start (ie. when it can be pinged).
3. wait_for_process : Waits for a configurable name to appear in the Erlang process registry.

{extended_start_script_hooks, [
{pre_start, [{custom, “hooks/pre_start”}]},
{post_start, [
{pid, “/tmp/foo.pid”},
{wait_for_process, some_process},
{custom, “hooks/post_start”}
]},
{pre_stop, [
{custom, “hooks/pre_stop”}]},
{post_stop, [{custom, “hooks/post_stop”}]},
]},
{post_stop, [{custom, “hooks/post_stop”}]}
]}.

1
2
3
4
5
6
## Extensions
The extended start script that is generated comes with a builtin set of commands that allows you to manage your release, these are start, stop, restart, etc.

Sometimes it's useful to expose some custom commands that are specific to your application. For example if you're running a game server it would be convenient to just call bin/gameserver games that outputs useful information.

Extended start script extensions allow you to create a custom shell script that gets appended to the list of commands available to your start script. The extension shell script can take arguments and has access to all shell variables defined in the start script itself. You begin by defining the extension in your rebar.config, for example:

% start script extensions
{extended_start_script_extensions, [
{status, “extensions/status”}
]}.

1
2
3
4
5
6

Here you are adding the status script extension that will invoke an extensions/status shell script.
This path is relative to the location of the start script on the generated release so you probably will want to use a overlay to place it at the correct location:
`{copy, "scripts/extensions/status", "bin/extensions/status"},`

The extension script itself is standard shell script, the game server example described could be implemented in the following way:

#!/bin/bash

case $1 in
help)
echo “bin/gameserver status”
;;
*)
;;
esac

get the status tuple from gameserver

Status=$(relx_nodetool eval “pool_debug:status(json).”)

now print it out

code=”Json = binary_to_list($Status),
io:format(\”~p~n\”, [Json]),
halt().”
echo $(erl -boot no_dot_erlang -sasl errlog_type error -noshell -eval “$code”)

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

## Booting, Upgrade and Inspecting
The extended start script that comes with relx and is set to be used by rebar3's release template, {extended_start_script, true}, provides a few ways of starting and connecting to your release.

For local development you'll like use console. In production you'll want start or foreground.

start creates a pipe that can be connected to later with the command attach. The Erlang VM calls fsync on every line of output in this mode, so foreground might be better for your use cases.

To open a console with a node started with foreground use remote_console.

**Appup generation**
For a detailed workflow including version increments and appup generation checkout Richard Jones relflow tool built around rebar3.

**Deploying an upgrade**
For the basic release upgrade after install of a release assume we have a release named myrel with a version 0.0.1 and 0.0.2:

1. Installing: Installing a release on a running system will unpack and upgrade the version: bin/myrel install 0.0.1
2. Listing: you can inspect what versions are currently available: bin/myrel versions
3. Upgrading: If the version is already unpacked you can simply call upgrade to upgrade to the version: bin/myrel upgrade 0.0.2
4. Downgrading: To downgrade to the previous version use the downgrade command: bin/myrel downgrade 0.0.1


#Plugins
Plugins can be installed locally to a project and globally. To install a plugin locally, specify it under plugins in your project's rebar.config. Globally installed plugins are configured in ~/.config/rebar3/rebar.config and automatically installed when you use a rebar3 command in your project.

##Including Plugins
Plugins required for building an application should be included under plugins in the same format as dependencies are listed in deps. They are built under the directory `_build/<profile>/plugins/` and are listed in the output of rebar3 help, available to use as tasks and in provider_hooks:

{plugins, [{rebar_erl_vsn, “~> 0.1”}]}.
{provider_hooks, [{pre, [{compile, {default, erl_vsn}}]}]}.

1
2
3
4
5
The above configuration will result in erl_vsn task being run before the compile task. This plugin adds defines to the compile configuration, such as if running on an Erlang version above 17 it will include {d, 'maps'} in erl_opts during compilation.
##Project Plugins and Overriding Commands
Some plugins work best if they are able to override the available commands. However, this isn't something that plugins should be able to do when the project they are included in is used as a dependency. project_plugins defines plugins that will only be available when the the project is being built directly by rebar3 commands, as in running rebar3 from the top level directory of the application/project.

For example the cuttlefish plugin is only necessary when building a release, so not fetching it and having it available per application dependency makes sense. It also works best if it works the same as building a release or tarball. So when included in project_plugins:

%%rebar.config
{project_plugins, [rebar3_cuttlefish]}.

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

Running rebar3 release or rebar3 tar will be running the rebar3_cuttlefish providers instead of the built in providers.

Additionally there are cases you only need a plugin for development. Say you have protobufs and commit the generated modules to the repo and include in the hex package, then there is no need for the protobuf plugin to be available when the application is a dependency and is only needed for development purposes. Before project_plugins it was common to see a dev profile with plugins added under it, but this then required running rebar3 as dev protobuf and dealing with another profile under _build. With project plugins the config can instead be:

`{project_plugins, [rebar3_gpb_plugin]}.`
Now we need only run rebar3 protobuf. We do not include any hooks because we will be committing the generated code to the repository and the plugin will not be fetched if this project is used as a dependency.

##Upgrading Plugins
Plugins work a bit like dependencies (although they are currently not being version-locked); they will not be automatically updated unless you ask for them to be.

1. You can upgrade project-local plugins by calling rebar3 plugins upgrade <plugin_name>.
2. You can upgrade global plugins by calling rebar3 as global plugins upgrade <plugin_name>, which invokes a hidden global profile used specifically to switch the upgrade context for plugins.

If you are using hex packages as plugins and you do not see the version you expected, remember to use call rebar3 update to get a fresh Hex index. Once again, since plugins are not locked as part of the lock file, it might be a good idea to always specify a version for them.


##Available Plugins
Auto-Compile and Load
Auto-Test
Hex Package Management
Port Compiler
Run Release
Alias
QuickCheck
PropEr
Diameter
ErlyDTL
Neotoma
Protocol buffers
Appup
Vendoring Dependencies
Elixir Dependencies

##Auto Compile and Load
For the auto plugin it is suggested to place the entry in the global rebar3 config which should be made as ~/.config/rebar3/rebar.config.
`{plugins, [rebar3_auto]}.`
Running rebar3 auto will start the shell the same as running rebar3 shell but will be listening for file changes in your project's application source directories. When a file is change it will message the rebar3 agent to run compile and reload modules.

##Auto-Test
For the autotest plugin it is suggested to place the entry in the global rebar3 config which should be made as ~/.config/rebar3/rebar.config.
`{plugins, [{rebar3_autotest, "0.1.1"}]}.`

Running rebar3 as test autotest will start eunit once and set watches for your source, header and test-files, so that it reruns eunit on changes on one of the files.

##Hex Package Management
For the hex plugin it is suggested to place the entry in the global rebar3 config which should be made as ~/.config/rebar3/rebar.config.
`{plugins, [rebar3_hex]}.`
For usage go to the Hex Package Management section and the Publishing Packages tutorial. To view the package go to hex.pm and to open issues Github

##Port Compiler
This plugin is provides the old rebar interface to building C and C++ code to rebar3. The package can be found on hex.pm and issues on Github.

In your project's rebar.config add the pc plugin and calls to it in provider_hooks for compile and clean:

{plugins, [pc]}.

{provider_hooks,
[
{pre,
[
{compile, {pc, compile}},
{clean, {pc, clean}}
]
}
]
}.

1
Configuration variables available:

%% Supported configuration variables:
%%
%% port_specs - Erlang list of tuples of the forms
%% {ArchRegex, TargetFile, Sources, Options}
%% {ArchRegex, TargetFile, Sources}
%% {TargetFile, Sources}
%%
%% port_env - Erlang list of key/value pairs which will control
%% the environment when running the compiler and linker.
%% Variables set in the surrounding system shell are taken
%% into consideration when expanding port_env.
%%
%% By default, the following variables are defined:
%% CC - C compiler
%% CXX - C++ compiler
%% CFLAGS - C compiler
%% CXXFLAGS - C++ compiler
%% LDFLAGS - Link flags
%% ERL_CFLAGS - default -I paths for erts and ei
%% ERL_LDFLAGS - default -L and -lerl_interface -lei
%% DRV_CFLAGS - flags that will be used for compiling
%% DRV_LDFLAGS - flags that will be used for linking
%% EXE_CFLAGS - flags that will be used for compiling
%% EXE_LDFLAGS - flags that will be used for linking
%% ERL_EI_LIBDIR - ei library directory
%% DRV_CXX_TEMPLATE - C++ command template
%% DRV_CC_TEMPLATE - C command template
%% DRV_LINK_TEMPLATE - C Linker command template
%% DRV_LINK_CXX_TEMPLATE - C++ Linker command template
%% EXE_CXX_TEMPLATE - C++ command template
%% EXE_CC_TEMPLATE - C command template
%% EXE_LINK_TEMPLATE - C Linker command template
%% EXE_LINK_CXX_TEMPLATE - C++ Linker command template
%%
%% Note that if you wish to extend (vs. replace) these variables,
%% you MUST include a shell-style reference in your definition.
%% e.g. to extend CFLAGS, do something like:
%%
%% {port_env, [{“CFLAGS”, “$CFLAGS -MyOtherOptions”}]}
%%
%% It is also possible to specify platform specific options
%% by specifying a triplet where the first string is a regex
%% that is checked against Erlang’s system architecture string.
%% e.g. to specify a CFLAG that only applies to x86_64 on linux
%% do:
%%
%% {port_env, [{“x86_64.*-linux”, “CFLAGS”,
%% “$CFLAGS -X86Options”}]}
%%
%% Cross-arch environment variables to configure toolchain:
%% GET_ARCH to set the tool chain name to use
%% GET_ARCH_WORDSIZE (optional - to determine word size)”
%% word size is 32
%% GET_ARCH_VSN (optional - “
%% l version of CC/CXX is requested),

1
2
3
4
5
6
7
8
9

##Run Release
rebar3 run will start the release console, instead of having to run _build/default/rel/<release>/bin/<release> console. Found at Github and hex.pm.
`{plugins, [rebar3_run]}.`

##Alias
The alias plugin has been added to rebar3 starting with version 3.5.0. See http://rebar3.org/v3/docs/configuration#section-alias for instructions.

For prior versions, the plugin for aliasing a single command to run multiple tasks can be found at Github and hex.pm.

{plugins, [rebar_alias]}.

{alias, [{check, [eunit, {ct, “–sys_config=config/app.config”}]}]}.

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

Arguments (as with a command line) can be passed by replacing Provider with {Provider, Args}.

##Quickcheck
A rebar3 plugin to enable the execution of Erlang QuickCheck properties. Found on Github and hex.pm.
`{plugins, [rebar3_eqc]}.`

Config options for the Quickcheck go under eqc_opts, for example {eqc_opts, [{numtests, 500}]}.:

|Config Option	|Type|	Description|
|----|----|----|
|numtests|integer|Number of test executions, default 100.|
|testing_time|integer|Time in seconds to execute property. If both are<br> specified, the testing_time setting is ignored.|

Similarly configuration can be passed on the command line:

|Option	|Type|	Description|
|----|----|----|
|-n|integer|Number of test executions, default 100.|
|-t|integer|Time in seconds to execute property. If both are specified, <br>the testing_time setting is ignored.|
|-p|string|Property to execute. This can be either module:property or<br> property and the plugin will determine the module.|


##PropEr
PropEr is a free alternative to Quviq Quickcheck. The plugin is available on hex as a package or github

%% the plugin itself
{plugins, [rebar3_proper]}.

%% The PropEr dependency is still required to compile the test cases
{profiles,
[{test, [
{deps, [{proper, “1.1.1-beta”}]}
]}
]}.

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
All of PropEr's configuration options can be passed in rebar.config under {proper_opts, Options} or as command line arguments:

|rebar.config key|	Command Line|	Description|
|----|----|----|
|{dir, String}|-d, --dir|directory where the property tests are<br> located (defaults to "test")
|{module, [Modules]}|-m, --module|name of one or more modules to test 
|{properties, [PropNames]}||-p, --prop|name of properties to test within a specified module|
|{numtests, N}|-n, --numtests|number of tests to run when testing a given property|
|`verbose | quiet`|-v, --verbose|Whether each property tested shows its <br>output or not (defaults to true/verbose)|
|`{cover, true | false}`|-c, --cover|generate cover data (default: false)|
|long_result|--long_result||enables long-result mode, displaying counter-examples<br> on failure rather than just false|
|{start_size, N}|--start_size|specifies the initial value of the size parameter|
|{max_size, N}|--max_size|specifies the maximum value of the size parameter|
|{max_shrinks, N}|--max_shrinks|specifies the maximum number of times a failing<br> test case should be shrunk before returnin|
|noshrink|--noshrink|instructs PropEr to not attempt to shrink any failing test cases|
|{constraint_tries, N}|--constraint_tries|specifies the maximum number of tries before the generator<br> subsystem gives up on producing an instance that <br>satisfies a ?SUCHTHAT constraint|
|{spec_timeout, Millisecs}|--spec_timeout|duration, in milliseconds, after which PropEr considers<br> an input to be failing|
|any_to_integer|--any_to_integer|converts instances of the any() type to integers in <br>order to speed up execution|


##Diameter
The rebar3_diameter_compiler plugin compiles diameter .dia files in rebar3 projects.
`{plugins, [rebar3_diameter_compiler]}.`

Add hooks to automatically compile and clean the diameter dictionaries:

{provider_hooks, [
{pre, [
{compile, {diameter, compile}},
{clean, {diameter, clean}}
]}
]}.

1
2
3
4
5
6
7
8
9
10
Configuration options:

|Config Option	|Type|	Description|
|----|----|----|
|dia_opts|list|Options from diameter_make:codec/2 <br>supported with exception of inherits.|
|dia_first_files|list|Files in sequence to compile first.|


##ErlyDTL
The erlydtl compiler has been moved to a separate plugin.

{plugins, [
{rebar3_erlydtl_plugin, “.*”,
{git, “https://github.com/tsloughter/rebar3_erlydtl_plugin.git", {branch, “master”}}}
]}.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Config options go in a list under erlydtl_opts in rebar.config:

|Config Option	|Type|	Description|
|----|----|----|
|doc_root|string|Where to find templates to compile.<br> "priv/templates" by d efault.|
|compiler_options|proplist|Template compilation options to pass<br> to erlydtl. Descriptions here.|
|out_dir|string|Where to put compiled template beam files "ebin" by default.|
|source_ext|string|The file extension the template sources have ".dtl" by default.|
|module_ext|string|Characters to append to the template's module <br>name "_dtl" by default.|
|recursive|boolean|Boolean that determines if doc_root(s) need <br>to be scanned recursively for matching<br> template file names. 'true' by default.|

##Neotoma
Plugin for building PEG files using Sean Cribbs neotoma app. This plugin is published to Hex so can be added to your project with:
`{plugins, [rebar3_neotoma_plugin]}.`
The compile function is under the neotoma namespace. To automatically before the Erlang compiler add the pre_hook to rebar.config:

{provider_hooks, [
{pre, [{compile, {neotoma, compile}}]}
]}.

1
2
3
4
5
##Protocol Buffers
Plugin for building .proto files using Tomas Abrahamsson's gpb. This plugin is published to Hex so can be added to your project with:

`{plugins, [rebar3_gpb_plugin]}.`
The compile function is under the protobuf namespace. To automatically build before the Erlang compiler add the provider pre hook to rebar.config:

{provider_hooks, [
{pre, [{compile, {protobuf, compile}}]}
]}.

1
2
3
4
5
6
7
Full documentation available in the plugin's README

##Appup
Plugin for generating, compiling and validating .appup.src files. This plugin is published to Hex so can be added to your project with:
`{plugins, [rebar3_appup_plugin]}.`

The compile and clean functions are under the appup namespace. To automatically build before the Erlang compiler add the provider pre hook to rebar.config:

{provider_hooks, [
{post, [{compile, {appup, compile}},
{clean, {appup, clean}}]}
]}.

1
To compare two releases and generate the .appup with the necessary instructions to execute the release upgrade run:

git checkout
rebar3 release
git checkout
rebar3 release
rebar3 appup generate
rebar3 relup tar
`

Argument Type Description
previous optional Path location of the previous release to compare with
current optional Path location of the current release to compare with,
defaults to _build/<profile>/rel/<app_name>
target_dir optional Location of where to generate the .appup file.
previous_version optional Version to update from

Full documentation available in the plugin’s README

##Vendoring dependencies
Plugin for storing vendored dependencies and applying the vendored deps to your local project.
{plugins, [rebar3_vendor]}.
To store the fetched dependencies under ./deps/ for committing:
rebar3 vendor store

To take the vendored dependencies from ./deps/ and place them under the build directory in the appropriate place:
rebar3 vendor apply

##Elixir Dependencies
Elixir dependencies can be supported and added to a project via the rebar3_elixir_compile plugin.

Full example and configuration instructions are provided on the plugin’s README page.

感谢您的赞赏,赚点辛苦奶粉钱