Since rebar_deps:get_deps_dir/1 returns an absolute path,
lists:member(Deps, Parts2) will always return false, thus .test.spec
files in deps/ will not be ignored.
On my slow old netbook with a 1.6GHz CPU, this inttest
takes about 40 seconds to run, of which network activity
is about 3s, the default timeout of retest is 30s.
Add a generous margin to avoid unnecessary timeouts.
For protocol buffer files, when there were gpb options to alter the
module name with prefix or suffix, recompilation was not properly
detected. This is now fixed. (Issue #384).
Properly detecting change meant moving from rebar_base_compiler, so it
also meant processing protocol buffer files in sequence instead of in
parallel.
exercises rebar/gpb integration
The bulk of these tests are written by Luis Rascão, hence he is the
author of this commit. As the committer, I have cherry-picked his two
commits 4c87bcd and ebb8182, from the feature/support_gpb_protobuf
branch in the git://github.com/lrascao/rebar repo, and have slightly
adapted it to fit this pluggable-proto-compilers-gpb branch.
Update the THANKS file
If you happen to fetch a zip archive of the git repo and try to build
from that, you may, for example, ask erlc to build src/._rebar.erl.
._* are OS X resource forks and not real .erl files. This may also
happen with network filesystems on OS X. To fix that, limit the
files compiled by rebar to include only those which start with
a letter or a digit.
Moves ct_extra_params to the end of the generated ct_run command.
This allows users to pass commands to the underlying emulator
using -erl_args. The included rt test demonstrates that it is
possible to pass an addtional option to ct_run and -erl_args at
the same time. Finally, the test executes in regular and verbose
modes because rebar constructs the ct_run command differently in
verbose mode.
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
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.
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.
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.
