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.
To avoid treating plugins' info/2 functions as commands, we catch calls
to 'rebar info'. Previously (4b8c81fb) we simply printed the help
string, but it's much more informative to print the following:
Command 'info' not understood or not applicable
For now, this is just a proof of concept; would make sense to add a lot
of things, such as quick access to invoking rebar itself (with approproate
code reloading), as well as an eunit-aware version so that tests could be
run interactively.
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.
