| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Breaking up initial call to parse from the ones deep inside the provider
parsing to do smarter namespace detection, added 'as' the ability to
look into these also, and cleaned up the code a whole lot that would
depend on implicit assumptions.
A side-effect is that 'do' is now valid for all namespaces, although it
can be overriden.
|
| | |
|
| |
|
|
|
|
|
| |
This adds some more convolution to command parsing, unfortunately, but
makes some cases clearer (`rebar3 as as as as` is no longer valid). It
unfortunately disallows using $REBAR_PROFILE along with `as` in a rebar
command.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Using a namespace such as 'rebar3 lfe new' will look for the 'new'
command in 'lfe' namespace without the need for a 'do' provider to be
registered in that namespace.
Manually checked that 'rebar3 as <profile> <namespace> command' works,
as well with 'default' and 'do'.
Test suite still needed.
|
| |
|
|
| |
And more general namespace support
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Removed separate compilers
Resolves apps to build
Finds avail deps before pulling/building
Includes relx
Simplifies build commands
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
REBAR will be set to the rebar binary which was executed and runs the
builds. Enables the use of the same binary for rebar invocations as
part of a pre or post hook like so:
${REBAR} escriptize
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the introduction of -r/--recursive, deps were not properly added
to the code path when running ct, eunit, etc.
To fix that, pass a flag down to process_dir1 and conditionalize
execution of the command. This moves the decision into process_dir1
where we can decide to invoke preprocess/2 and postprocess/2 but not
execute the command.
Without this fix, you'd have to, for example, invoke 'rebar -r ct
skip_deps=true', if you wanted to run base_dir's ct suites with deps on
the code path (while skipping all non-base_dir ct suites).
So, with this patch applied, if you run
$ rebar ct
deps will be on the code path, and only base_dir's ct suites will be
tested.
If you want to test ct suites in base_dir and sub_dirs, you have to run
$ rebar -r ct skip_deps=true
If you want to test ct suites in all dirs, you have to run
$ rebar -r ct
The fix is not specific to ct and applies to all commands.
To be able to add inttest/code_path_no_recurse/deps, I had to fix
.gitignore. While at it, I've updated and fixed all entries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix arg order:
The order of arguments got inconsistent over time. To fix that, use
the same consistent order in all functions.
* Avoid one erlang:'++'/2 call in process_dir/6.
* Avoid lists:prefix/2 and atom_to_list/1 calls:
We can easily avoid 2 lists:prefix/2 calls and one atom_to_list/1 call
in execute/5 by passing in whether the command is a hook or not. The
resulting code is simpler and easier to read.
|
| |
|
|
|
|
|
|
|
|
| |
If the directory we're about to process contains
reltool.config[.script] and the command to be applied is
'generate', then it's safe to process. We do this to retain the
behavior of specifying {sub_dirs, ["rel"]} and have "rebar generate"
pick up rel/reltool.config[.script]. Without this workaround you'd
have to run "rebar -r generate" (which you don't want to do if you
have deps or other sub_dirs) or "cd rel && rebar generate".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
