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.
- 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
Introduce a new 'raw' option for dependency specs in rebar.config file.
For example:
{deps,
{dependency_name, "1.0.*",
{git, "<...>", {branch, "master"}},
[raw]
}
]}.
When this option is specified, rebar does not require the dependency to
have a standard Erlang/OTP layout which assumes presence of either
"src/dependency_name.app.src" or "ebin/dependency_name.app" files.
'raw' dependencies can still contain 'rebar.config' and even can have
the proper OTP directory layout, but they won't be compiled.
Only a subset of rebar commands will be executed on the 'raw'
subdirectories:
get-deps, update-deps, check-deps, list-deps and delete-deps.
When rebar ct executes with its default common test directory of "test",
it will generate a hardcoded "logs" directory in every application with
a test directory present, causing an overlap with eunit's test framework
so even test directories with only eunit tests will be processed by ct.
Not every system under test can be run with long names, and this makes
rebar's common_test support useless in those environments, as it
currently uses long names (test@hostname.domain) by default, without
recourse to change them.
This patch adds support for a {ct_use_short_names, boolean()} config
variable, which allows the user to specify whether short or long names
are required.
The custom queries are configured in rebar.config via the tuple
{xref_queries, [{query(), query_result()},...]}. The implementation
passes the query() string to xref:q and compares the return value with
query_result(). It will result in an error if they do not match.
The following configuration, for example, is the same as running the
xref check undefined_function_calls. It additionally filters
ejabberd_logger:*_msg/4 from the result as these functions are generated
on execution by ejabberd and not available at compile time.
{xref_queries, [{"(XC - UC) || (XU - X - B -
(\"ejabberd_logger\":\".*_msg\"/\"4\"))",[]}]}.
This patch also modifies the build process of this package by running a
custom query instead of doing a diff against a static xref_warning file.
This patch allows users to specify the directory in which common_test
source files can be found. Most common_test suites are integration,
rather than unit tests and keeping the sources apart from test sources
for other frameworks such as eunit and PropEr is a useful feature.
This patch updates rebar_core to look for missing plugins (i.e. those
that aren't found on the code path at runtime) in a configurable
plugin directory, and dynamically compile and load them at runtime.
By default, the directory "plugins" is searched, although this can be
overriden by setting the plugin_dir in your rebar.config.
Change the second parameter of a regex tagged port_source from being a
filename or wildcard to being a list of filenames or wildcards.
Previously: {"R14", "c_src/*.c"}
Now: {"R14", ["c_src/*.c"]}
Motivation for change is to avoid repeating regexes.
This change makes it possible to assign pre/post scripts to all
rebar commands. This allows users fine grained control over
when scripts and/or shell commands should be executed, where such
extensions are absolutely needed.
Several examples have been added to the rebar.config.sample file.
