It is now possible to call rebar as:

  rebar xref skip_app=Mod1,Mod2,...

This makes it easy to skip running xref on (e.g)
imported dependencies in your application.

The function rebar_utils:is_skipped_app/0 is added so
that other rebar commands may use it.

Previously if erl_interface could not be found {error, not_found} was
incorrectly used as a path. With this change we fail early with a
descriptive error message.

{pre_hooks,  [{"linux", compile, "c_src/build_linux.sh"}]}.
{post_hooks, [{"linux", compile, "c_src/build_linux.sh clean"}]}.

This patch adds support for first_files to the port_compiler, via the
new `port_first_files` rebar config element.

When generating a node using rebar generate, rebar always used
code:root_dir() to find the Erlang installation to clone into the node
tree.  However, for anyone wishing to build a cross-compiled node, there
was no way to override this.  This patch adds a new option to
reltool.config file to allow an alternate root_dir to be specified, for
example:

{root_dir, "/tmp/otp_R14B03_armv7l"}

This assumes that the contents of /tmp/otp_R14B03_armv7l has been
generated using the instructions found in the xcomp directory in your
$ERL_TOP structure.  NOTE: you may have to add additional filters to
exclude files not present in the xcomp version, such as the .smp files
if you have disabled that.

This means that applications get a chance to shut down themselves,
before rebar will start killing their processes.  This avoids ERROR
REPORTS from application supervisors.

The function may fail with a badarg exception because the first regex
returns an iolist() which is allowed to be a improper list. In this case
'++' cannot append to the iolist. The correct way to append something to
an iolist() is

  [iolist(), "tail"]

because iolist's are allowed to be arbitrarily deep lists.

The introduction of setup_env as a global concept caused the rebar_port_compiler
implementation to start getting called a LOT. The expansion of environment variables
that happens in the port compiler was O(n^n), which means you could see upwards of
80k invocations of lists:foldl on a single app "./rebar clean". This commit reworks
the expansion to be O(n^2), and reduces the running time for the same operation by
60%+. On a large project like Riak, the end result is that a build went from 200
seconds to 73.

Simple feature, useful to make link to something without copying it.

For parameterized modules, the beam code will have a compiler
generated new/1 and instance/1 function.

If while checking the beam, xref detects one of those is unused, the
rebars xref wrapper will try to find the location of the definition of
that function in the source code for the module (to give a more
specific warning to the user). Since the function was generated by the
compiler it does not actually exist in the source, and rebar crashes
at that stage. This patch works around that issue.

required for building on a different machine to what your live
config is kept on. This way you can build on one machine,
distribute to new machine, then run overlays against a live
config to prevent accidently running code against a live
config in a development or ci environment.

Setup code path prior to calling edoc so that edown, asciiedoc,
and the like can work properly when generating their own
documentation.

This patch modifies rebar_core to allow plugins to participate in the
pre and post processing steps, giving plugin authors more flexibility
and control.

Currently rebar_utils:sh/2 will invoke all commands through bash.exe if
found. Otherwise the command will be executed directly. Despite the fact
that the caller cannot know if the command is executed with Unix or
Windows semantics it leads to problems with MSYS's automatic path name
translation.

Therefore remove bash usage on Windows to get a consistent behavior and
to avoid the peculiarities of MSYS's automatic path conversion. Instead
use cmd.exe as its typically needed by most commands.

Args provided by erlsrv.exe were being mostly
discarded due to being processed through set_trim

While building a upgrade package rebar will add new paths to the
internal erlang path, these paths and their order have effects on how
the package is built. This patch should fix some corner cases where a
user can receive a "undefined application" error.

While building an upgrade the sys.config file should be copied into the
upgrade tarball so release_handler:install_releases/1 does not clobber
the existing configuration from the application environment.

In debugging upgrade issues it is sometimes difficult to know which
systools step a error ocurred at, a little extra logging to fix that.

This patch adds support for customising the way in which rebar generates
version numbers for app.src files using the `{vsn,Spec}` approach.
Whilst the existing `{vsn,ScmName::atom()}` syntax will continue to
work, users can also pass `{vsn,{cmd,Cmd::string()}}` in which
case the provided *command* will be used. For example:

```erlang
{application, doodah,
 [
  {vsn, {cmd, "git rev-parse --short HEAD"}}]}.
```

This patch corrects the vm.args behavior while building upgrade tarballs
by copying the file from the release into the upgrade. Additionally it
patches the dummy runner script in the upgrade test project to work
properly.

Avoid overwriting custom config (passed with -C) when we are processing
the base_dir in rebar_core.

@ characters causes windows start_erl error