proto_opts config option contains the compiler directive
that defines which proto compiler to use, also contains a
src_dirs entry that defines a list of locations for the
.proto files to be processed.
Add integration test that compiles .proto files from src
and from proto directory specified in separate rebar
config files
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.
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
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
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.
