{recursive_cmds, []} was already documented as part of the core
rebar.config options that gets printed via 'rebar -h', but this wasn't
sufficiently informative. To fix this, explain the use of
recursive_cmds as part of the -r help string.
Reported-by: Stefan Strigler
* Refactor reltool version check to use vsn app key if ebin/reltool.app
exists.
OTP releases prior to R14 didn't install the app file, so we still
have to support getting the version string from the lib_dir path. If
you're using an R13B03 or R13B04 install that doesn't have version
strings in lib_dir paths (lib/reltool vs lib/reltool-0.5.3), we won't
be able to retrieve the version string. Given R13's age and that it's
unusual to have vsn-less lib_dir paths, this shouldn't be a problem.
* While at it, delete trailing white space.
This reverts commit 81063d33f0, reversing
changes made to 6584defdda.
This was reverted because it changed the gpb compiler to
not use rebar_base_compiler. That change was to add support for
target name prefixes, but it is better to add that support to
rebar_base_compiler.
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.
