REBAR will be set to the rebar binary which was executed and runs the
builds. Enables the use of the same binary for rebar invocations as
part of a pre or post hook like so:
${REBAR} escriptize
The combination of changes to rebar_erlc_compiler, and the fact
that erl_first_files is inherited, caused a regression. To fix
that, ensure every project uses its own .rebar/erlcinfo. While at
it, fix the issue that erl_first_files entries were not included
when initializing the dep digraph.
Reported-by: Louis-Philippe Gauthier
Reported-by: Roland Karlsson
Thanks: Tuncer Ayaz
When trying to skip spec files under deps/ directory,
ignore "deps" component which is also included in Cwd.
For example, "/home/deps/src/myapp/test/cover.spec"
contains "deps" component but should not be skipped if
Cwd is "/home/deps/src/myapp/".
Augment 'tests' option of 'rebar eunit' command with ability to specify
tests to run using module-qualified names. This change also forced me
to change the way modules for coverage and for testing itself are
selected - module-qualified tests specifications are now taken into
consideration. Extend tests to cover new functionality. Update
dialyzer_reference accordingly.
attempt to emulate the behavior of
`erl -pa ebin -pa deps/*/ebin`
fix error messages and formatting issues of `rebar shell` by
shutting down and restarting the user subsystem in a mode more
hospitable to the shell than the simple user started when run
as an escript. emulate `error_logger` behaviour when the shell
is run via `erl`
add documentation of the shell command
limitations:
the erlang interrupt handler is not enabled when running as an
escript and there is no interface to re-enable it via erlang code.
this means `ctrl-c` will immediately exit the running process
unlike when running the shell via `erl`. `ctrl-g` is, however,
unaffected
the user subsystem is killed and restarted but not supervised. if
your code somehow relies on the user subsystem crashing and
restarting `rebar shell` may interfere with it's operation
On windows, bootstrap.bat failed with next error.
Command 'escriptize' not understood or not applicable
This happens because the drive name in path got from rebar_utils:get_cwd() and base_dir(Config) are different case.
Made the drive name the same lowercase using filename:absname().
Since the introduction of -r/--recursive, deps were not properly added
to the code path when running ct, eunit, etc.
To fix that, pass a flag down to process_dir1 and conditionalize
execution of the command. This moves the decision into process_dir1
where we can decide to invoke preprocess/2 and postprocess/2 but not
execute the command.
Without this fix, you'd have to, for example, invoke 'rebar -r ct
skip_deps=true', if you wanted to run base_dir's ct suites with deps on
the code path (while skipping all non-base_dir ct suites).
So, with this patch applied, if you run
$ rebar ct
deps will be on the code path, and only base_dir's ct suites will be
tested.
If you want to test ct suites in base_dir and sub_dirs, you have to run
$ rebar -r ct skip_deps=true
If you want to test ct suites in all dirs, you have to run
$ rebar -r ct
The fix is not specific to ct and applies to all commands.
To be able to add inttest/code_path_no_recurse/deps, I had to fix
.gitignore. While at it, I've updated and fixed all entries.
* Fix arg order:
The order of arguments got inconsistent over time. To fix that, use
the same consistent order in all functions.
* Avoid one erlang:'++'/2 call in process_dir/6.
* Avoid lists:prefix/2 and atom_to_list/1 calls:
We can easily avoid 2 lists:prefix/2 calls and one atom_to_list/1 call
in execute/5 by passing in whether the command is a hook or not. The
resulting code is simpler and easier to read.
If the directory we're about to process contains
reltool.config[.script] and the command to be applied is
'generate', then it's safe to process. We do this to retain the
behavior of specifying {sub_dirs, ["rel"]} and have "rebar generate"
pick up rel/reltool.config[.script]. Without this workaround you'd
have to run "rebar -r generate" (which you don't want to do if you
have deps or other sub_dirs) or "cd rel && rebar generate".
Allow rebar to compile applications using Erlang/OTP 17 and older
versions. This patch only provides partial support since the rebar
tool itself must be compiled using an Erlang/OTP version that is older
than 17.
This calls the 'p4' command-line tool to checkout and sync Perforce
trees. It involves significantly more special code in Rebar than
using 'git p4', but it eliminates the indirection of
Rebar->Git->Python->Perforce
Using the filename as a prefix is less readable and inconsistent with
the other log messages.
Before:
DEBUG: src/foo.erl depends on...
After:
DEBUG: Dependencies of src/foo.erl ...
Running 'rebar list-templates' can take quite a long time, when it has
to search the file system. To fix that, make list-templates not recurse
by default. To enable recursion, run 'rebar -r list-templates'.
Always-on recursive application of all rebar commands causes too many
issues. Recursive application is required for:
1. dealing with dependencies: get-deps, update-deps, and compile of deps
right after get-deps or update-deps
2. projects with a riak-like apps/ project structure and dev process
The vast majority of projects are not structured like riak. Therefore,
moving forward it's best to (by default) restrict recursive behavior to
dealing with deps. This commit does that and also adds command line and
rebar.config options for controlling or configuring recursion. Also, we
introduce two meta commands: prepare-deps (equivalent to rebar -r
get-deps compile) and refresh-deps (equivalent to rebar -r update-deps
compile). riak-like projects can extend the list of recursive commands
(to include 'eunit' and 'compile') by adding
{recursive_cmds, [eunit, compile]} to rebar.config.
* update files
* fix Dialyzer warning
* unconditionally enable info fil
* clean-up inconsistencies
* use term_to_binary compression
* use try...catch instead of case...catch...of
* do not write build info file if the graph is unmodified
* store info file as <base_dir>/.rebarinfo
* properly support list of compile directives
* fix regressions:
- Fix a bug in handling of files to compile first.
- If a file that is depended upon itself depends on other files, make sure
those are compiled first. While at it, rename variables for correctness.
Reported-by: David Robakowski
- Make sure that FirstFiles has no dupes and preserves the proper order.
- headers referenced via -include_lib() were not properly resolved to absolute
filenames
- .erl files found in sub dirs of src_dirs were not properly resolved to
absolute filenames
* Do not parse source files twice while checking for relationship.
* Keep files relationships in a graph.
* The option 'keep_build_info' is introduced. When set to 'true'
the graph will be kept in ebin/.rebar.build.info and will be
used by further compiler calls. The default is 'false'.
Option takes either 'true' or a numeric seed value. If true is passed, a
random seed is generated and used. The numeric seed value is for
repeatability.
The idea here is to root out test suites that are order dependant, or
that fail in the presence of certain orderings.
If the syntax error is in a .hrl file, then the reported error message
is not as useful because it's not clear which .erl file was being
compiled. We can fix that easily by first printing what source file was
being processed. We don't change the actual error message, so this will
still work with your editor of choice for jumping to the right line.
Before
------
Success:
Compiled src/foo.erl
Failure:
include/foo.hrl:10: syntax error [...]
After
-----
Success:
Compiled src/foo.erl
Failure:
Compiling src/foo.erl failed:
include/foo.hrl:10: syntax error [...]
To avoid treating plugins' info/2 functions as commands, we catch calls
to 'rebar info'. Previously (4b8c81fb) we simply printed the help
string, but it's much more informative to print the following:
Command 'info' not understood or not applicable
Previous generate-upgrade required renames in rel/ directory:
rebar generate
...changing code...
mv rel/<release> rel/<release_prev>
rebar generate
rebar generate-upgrade previous_release=<release_prev>
With the proposed changes you can now do the same without moving things:
rebar generate # default target dir: rel/<release>
...changing code...
rebar generate target_dir=<release_new>
rebar generate-upgrade target_dir=<release_new> previous_release=<release>
rebar used to mistakenly report plain version strings like
{vsn, "1.0.0"} as follows:
DEBUG: vcs_vsn: Unknown VCS atom in vsn field: "1.0.0"
Properly detect unknown/unsupported version terms and abort
if we encounter one.
While at it, rename a variable in vcs_vsn/3 to be non-misleading.
Rebar, when it encounters a lib_dir directive, caches the current code
path, adds the libdir(s) and returns the cached copy of the path. When
rebar has finished processing that directory, it restores the cached
path. This is problematic in the below scenario:
/(lib_dir)->G
A -> B -> C -> D -> E
\-> F -> D -> E
When rebar is finished processing B, it restores the code path to what
it was before it processed B, removing C, D, E and G from the code path.
This means when it comes to process F, neither D or E are in the code
path, so any header includes, rebar plugins or parse transforms will not
be in the code path. Without the lib_dir directive, rebar does no code
path cleanups, so everything works fine.
This change makes rebar only remove the explicit lib_dir code paths it
added and adds an inttest that replicates the above scenario.
Sometimes tags like 1.1-3-g3af5478 or d20b53f0 are encountered. The
first is the output of 'git describe', and the second is just a regular
git SHA. git fetch --tags will not pull these down, so do a full git
fetch instead.
Because rebar_core handles skipping apps, we had to specialcase the
handling in the case of update-deps because it has to do its own dep
handling. The way this was done is not particularly clean, but there
currently does not exist another way for a command to signal rebar_core
that it doesn't want rebar_core to pay attention to skip_apps.
With this change, however, you can update-deps even with local
conflicting changes/commits by simply skipping the deps you don't wish
to update, or whitelisting he ones you do wish to update.
Previously, update-deps on a dep tagged as {branch, ...} would do the
following:
git fetch
git checkout -q origin/<branch>
If you were already on that branch, the repo would end up in detached
head state. This is kind of annoying if you're doing local development.
This patch changes the behaviour to be
git fetch
git checkout -q <branch>
git pull --ff-only --no-rebase -q <branch>
The intent of this is to move the branch's HEAD forward to match
upstream without destroying any local commits or changes, and without
accidentally causing merges or rebases. It will fail if the operation
can not be performed without losing history, merging or rebasing.
The previous behaviour has been around a very long time:
064195dc5a (L0R308)
It also exactly mirrors the download_source case, which is not really
true. With git tags and SHAs, one can assume that they don't change, but
branches move all the time.
The order in which modules, within an application, are loaded can be
important. This patch adds allows the specification of module
dependencies such that generate .appup/.relup scripts will load a
module's dependent modules before itself.
To use:
in rebar.config, add a module_deps
{module_deps, [{ModuleName, [DependentModuleName, ...]}]}.
ModuleName is the name of any module, followed by a list of module
names that it depends on.
The call to the grep program in rebar_ct:check_log/3 used single
quotation marks around the strings grep should search for. This works
well in most cases but fails on Windows 7 using GNU grep 2.5.4 as
installed by the Chocolatey package GnuWin 0.6.3.1 with the follow
message:
ERROR: cmd /q /c grep -e 'TEST COMPLETE' -e '{error,make_failed}'
ct/raw.log
failed with error: 2 and output:
grep: COMPLETE': No such file or directory
This commit changes the single quotation marks to double quotation
marks. I've tested this using GNU grep 2.5.3 on a Debian Linux machine
and it works well.
This ensures that deps of deps are updated AFTER the dep listing them
is, so that a complicated project with many layers of deps will be
updated correctly. Any new deps encountered along the way are also
cloned, and THEIR deps are also evaluated.
Also added was conflict detection, if a dep has differing versions or
source information, inherited from different places, that will be logged
at the end of update-deps, along with the origin of each conflicting
dep.
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.
- restore support for "rebar help xref"
- update rebar.config.sample
- update 'help xref' string
- simplify new/changed functions by breaking out code or
using simpler syntax where applicable
- refactor plugin dirs code to be simpler and easier to read
- use erlang-mode's default (%%) comments for portability/consistency
- make sure erlang-mode's indenter is used so that a future whole
buffer indent doesn't get messed up
