Rebar is a build tool from the good folks at Basho that makes building and testing your project much easier. Rebar can find all the dependencies of your project, download them from GitHub or other sources, compile, build, test and package them for distribution.
For this book we are interested in how to gather dependencies, build and run our tests.
Rebar configuration is done with a rebar.config file in the project root directory. The rebar.config file is at its core a set of Erlang terms that describe the project. There are a number of options that are in common usage.
If your project contains a number of sub directories then use the {sub_dirs, []} directive to list the directories in which each part of the project will live in.
In addition if your project is dependent on external libraries (as most are) then you can list those in the {deps, []} directive. It will look like this example.
{deps, [
{webmachine, "1.9.*", {git, "git://github.com/basho/webmachine", "HEAD"}},
{jsx, ".*", {git, "git://github.com/talentdeficit/jsx.git", "HEAD"}},
{jsxd, ".*", {git, "git://github.com/Licenser/jsxd.git", "HEAD"}}]}.The final element which is "HEAD" here can be any refrence to a git commit. In most cases it is probably better to not use "HEAD" but to use an explicit tag or SHA1 value. This is because if you use "HEAD" it is possible for whomever owns the repository to update the code and when you next load your dependencies you will have a new, unknown and untested code base. While if you use an explicit tag then you will always get a known version of the state. More importantly if different developers (or different environments) last pulled in the dependencies at different times then with an explicit SHA1 value then you can be sure that they will all be using an identical version of the code.
#TODO: Explain the format of the dependencies directive
To actually download the dependencies run rebar get_deps it will go and clone all of the repositories from github or other on-line sources into your deps directory. In addition it will also download any of the dependencies of those projects.
This can also be a good way to break apart a large project. By creating several smaller applications each with their own repository and then pull them together with rebar. This means that each project will stand alone and can be built and tested in isolation. This is a good way to deal with a long build process. By having 10-12 git repositories each with their own tests and CI jobs it will ensure that CI does not get out of hand, and that all tests run in a reasonable amount of time.