6996cd4fcc
If running e.g. rebar generate using an OTP development build, rebar will complain that reltool has the version "", which is less than the required "0.5.2". This is because rebar_reltool simply checks the path returned by code:which(reltool), which doesn't yield version information if used in a development build. This patch substitutes a more robust method (load reltool and fetch the info from application:loaded_applications()). As it happens, this will not be enough to make things work, but now Reltool will explain that it cannot generate a spec from a system that is not installed, giving a better hint as to what needs to be done. |
||
|---|---|---|
| ebin | ||
| include | ||
| inttest | ||
| priv | ||
| src | ||
| test | ||
| .gitignore | ||
| .hgignore | ||
| .hgtags | ||
| .travis.yml | ||
| bootstrap | ||
| bootstrap.bat | ||
| dialyzer_reference | ||
| LICENSE | ||
| Makefile | ||
| NOTES.org | ||
| README.md | ||
| rebar.config | ||
| rebar.config.sample | ||
| rebar.config.script | ||
| THANKS | ||
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:
One line summary (less than 50 characters) Longer description (wrap at 72 characters)
Summary
- Less than 50 characters
- What was changed
- Imperative present tense (fix, add, change)
Fix bug 123Add 'foobar' commandChange 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
Run checks
Before you submit a patch, run make check to execute
the test suite and check for
xref and
Dialyzer
warnings. You may have to run make clean first.
Dialyzer warnings are compared
against a set of safe-to-ignore warnings found in
dialyzer_reference.
xref is run with
custom queries
to suppress safe-to-ignore warnings.
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.