01fd873c1e
Previously, the configuration setting 'mib_opts' in rebar.config
would affect the call to snmpc:compile/2, so that (for example)
verbosity could be controlled. However, the subsequent call to
snmpc:mib_to_hrl/1 did not include any of these options, so it
did not appear to be possible to control the verbosity of the
process of converting a MIB to a .hrl file. To make matters
worse, the default was to dump a full trace -- including debug
output and various logging -- so the act of compiling a large
number of MIBs could result in a huge amount of "noisy" output
that hid any signal (meaningful warnings, errors, etc.).
This commit addresses that issue by replacing the call to
snmpc:mib_to_hrl/1 with a call to snmpc:mib_to_hrl/3 instead,
which includes an "options" argument that, at present, is only
capable of setting verbosity. The verbosity setting is taken
from the 'mib_opts' setting in rebar_config, if present, and
the approriate kind of argument is passed to snmpc:mib_to_hrl/3.
It should be noted that snmpc:mib_to_hrl/3 is not listed in
Erlang's documentation, but does appear in the list of "API"
exports at the top of snmpc.erl in R15B01 (and remains that way
in R16B01), so this appears to be more of a documentation oversight
than the use of a deep, dark function call that was not intended
to be public. snmpc:mib_to_hrl/3 accepts an #options{} record
(defined in lib/srdlib/include/erl_compile.hrl within Erlang's
source distribution), though most of the fields in that record
are ignored by snmpc:mib_to_hrl/3; only verbosity can be controlled
this way.
|
||
|---|---|---|
| ebin | ||
| include | ||
| inttest | ||
| priv | ||
| src | ||
| test | ||
| .gitignore | ||
| .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/rebar/rebar/wiki/rebar
Building rebar
$ git clone git://github.com/rebar/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.
Community and Resources
In case of problems that cannot be solved through documentation or examples, you may want to try to contact members of the community for help. The community is also where you want to go for questions about how to extend rebar, fill in bug reports, and so on.
The main place to go for questions is the rebar mailing list. If you need quick feedback, you can try the #rebar channel on irc.freenode.net. Be sure to check the wiki first, just to be sure you're not asking about things with well known answers.
For bug reports, roadmaps, and issues, visit the github issues page.
General rebar community resources and links:
- Rebar Mailing List
- #rebar on irc.freenode.net
- wiki
- issues