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.
Loading .app, .app.src or .app.src.script returns now the value as per
the documentation (was wrapped in a list in some cases).
More places in the code detect .app.src.script and handle it.
rebar_app_utils:is_app_dir/1 failed to search for .app.src.script when
looking for an app file in src/.
While at it, fix inconsistent module export list.
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.
This adds the config option {proto_compiler,gpb} for selecting gpb
as the compiler for protocol buffer files. When gpb is used as
compiler, it reads the gpb_opts config item for options.
Make it possible for plug in alternative protocol buffer compilers.
The compilers are picked up based on if they export all of the
functions key/0, proto_compile/3, proto_clean/3 and proto_info/2.
The set of compiler modules to choose from, is fetched from the rebar
application environment, from the app_dir modules.
A new config option, {proto_compiler,Compiler}, specifies which of
the available protocol buffer compilers to use. The 'protobuffs'
compiler is now one such compiler (the only one), and it is also the
default, for backwards compatibility.
Function format_source in rebar_deps.erl will fail on sources
like {rsync, Path} or {hg, URL} in rebar.config.
Add new function clause to match such source types.
When the option {cover_print_enabled, true} is set and that the code
coverage is 100%, the '%' will end up being truncated.
This patch makes it so that the truncation happens at 4 a characters
width so that instead of the following printouts:
some_mod : 99%
some_other: 100
We instead show:
some_mod : 99%
some_other: 100%
This solves issue #331 as reported by @lispking and @NineFX.
Using code:set_path/1 with very large paths is very slow on larger
projects. On my mid-sized project, it seems to take around .4s per
call. Emulating the call with direct path removal (using
code:del_path/1) seems to be quite a lot faster.
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.
As mentioned in the OTP documentation, licensed customers may use
patched OTP installations where the otp_patch_apply tool adds a '**'
suffix as a flag saying the system consists of application versions from
multiple OTP versions. When we get such a version string, we drop the
suffix, as we cannot obtain relevant information from it as far as
tooling is concerned.
ensure any processes with a reference to an old user process as their
group leader are updated to use the new user process. this introduces a
slight delay at startup as the system must wait for the new processes
to be registered. there is a max wait period of three seconds (before
the shell command gives up and throws a timeout error)
fixes#314 ("rebar shell" somehow blocks using io:format in gen_server
handle_call)
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.
Partially revert naming changes introduced in 93689703c1:
CoverageModules -> FilteredModules
get_coverage_modules -> get_matching_modules
Having the name "coverage" meaning "filtered/selected modules" can be
confused with code coverage.
- Use `cover' with QuickCheck testing
- Reuse the `cover_*' rebar.config options
- Refactor cover-related code to separate module (`qc_cover_utils')
for use with both `eunit' and `qc'
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
