Rebar rebar. config

When using rebar to build a system, you can manually create a rebar. config file to configure the rebar.

Two parameters are important in this file.

% Where to put any downloaded depandencies. Default is 'deps'

Where to store the dependent applications downloaded from the network

?

1	{deps_dir, ["deps"]}.

In fact, this parameter also has another meaning, that is, the directory specified in deps_dir, which can be used as the storage directory of the current project dependent project.

When a rebar is used for building, the rebar searches for related dependencies in the directory specified by deps_dir.

% What dependences es we have, depandencies can be of 3 forms, an application

% Name as an atom, eg. mochiweb, a name and a version (from the. app file), or

% An application name, a version and the SCM details on how to fetch it (SCM

% Type, location and revision). rebar currently support git, Hg, bzr and SVN.

?

12345

{deps, [application_name,           {application_name, "1.0.*"},           {application_name, "1.0.*", {hg, "http://bitbucket.org/basho/rebar/", "f3626d5858a6"}}]}.

Deps parameters are clearly described. Rebar supports obtaining dependent projects from the SCM system.

The dependencies obtained from SCM are stored in the directory specified by deps_dir. Currently, four SCM types are supported: Hg, SVN, Hg, and bzr.

In addition, the deps parameter supports Erlang regular expressions. In this way, we can control the version of the dependent application.

The rebar also supports compiling the driver code, although the support is not complete.

You can use the script specified by port_pre_script to compile C/C ++.

% Tuple which specifies a pre-compilation script to run, and a filename that

% Exists as a result of the script running.

?

1	{port_pre_script, {"script.sh", "skipfile"}}.

Building such an Erlang project is not a big problem.

 

Reprinted: http://www.erlangsir.com/2011/05/27/rebar-rebar-config/