commit	0f24d9325659742da8b829fbd5b82ba0cec169da	[log] [tgz]
author	Dave Smith <dizzyd@dizzyd.com>	Mon Jun 04 08:46:17 2012 -0600
committer	Dave Smith <dizzyd@dizzyd.com>	Mon Jun 04 08:46:17 2012 -0600
tree	2eb54bd1a88492acb462cd1553ad643891cecb15
parent	c13889618d0ad921e4e6ab07a0aae1560e8ac988 [diff]

tree: 2eb54bd1a88492acb462cd1553ad643891cecb15

README.md

rebar

rebar is an Erlang build tool that makes it easy to compile and
test Erlang applications, port drivers and releases.

rebar is a self-contained Erlang script, so it's easy to distribute or even
embed directly in a project. Where possible, rebar uses standard Erlang/OTP
conventions for project structures, thus minimizing the amount of build
configuration work. rebar also provides dependency management, enabling
application writers to easily re-use common libraries from a variety of
locations (git, hg, etc).

Building

Information on building and installing Erlang/OTP can be found here (more info).

Dependencies

To build rebar you will need a working installation of Erlang R13B03 (or later).

Should you want to clone the rebar repository, you will also require git.

Downloading

You can download a pre-built binary version of rebar from:

https://github.com/basho/rebar/wiki/rebar

Building rebar

$ git clone git://github.com/basho/rebar.git
$ cd rebar
$ ./bootstrap
Recompile: src/getopt
...
Recompile: src/rebar_utils
==> rebar (compile)
Congratulations! You now have a self-contained script called "rebar" in
your current working directory. Place this script anywhere in your path
and you can use rebar to build OTP-compliant apps.

Contributing to rebar

Pull requests and branching

Use one topic branch per pull request.

Do not commit to master in your fork.

Provide a clean branch without any merge commits from upstream.

Usually you should squash any intermediate commits into the original single commit.

Code style

Do not introduce trailing whitespace.

Do not mix spaces and tabs.

Do not introduce lines longer than 80 characters.

erlang-mode (emacs) indentation is preferred. vi-only users are encouraged to give Vim emulation (more info) a try.

Writing Commit Messages

Structure your commit message like this:

Summary

Less than 50 characters
What was changed
Imperative present tense (fix, add, change)
- Fix bug 123
- Add 'foobar' command
- Change default timeout to 123
No period

Description

Wrap at 72 characters
Why, explain intention and implementation approach
Present tense

Atomicity

Break up logical changes
Make whitespace changes separately

Dialyzer and Tidier

Before you submit a patch check for xref and Dialyzer warnings.

A successful run of make check looks like:

$ make check
Recompile: src/rebar_core
==> rebar (compile)
Command 'debug' not understood or not applicable
Congratulations! You now have a self-contained script called "rebar" in
your current working directory. Place this script anywhere in your path
and you can use rebar to build OTP-compliant apps.
==> rebar (xref)
make: [dialyzer_warnings] Error 2 (ignored)

xref and Dialyzer warnings are compared against a set of safe-to-ignore warnings
found in dialyzer_reference and xref_reference.

It is strongly recommended to check the code with Tidier.
Select all transformation options and enable automatic
transformation.
If Tidier suggests a transformation apply the changes manually
to the source code.
Do not use the code from the tarball (out.tgz) as it will have white-space changes
applied by Erlang's pretty-printer.