| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
60s still seems to be too low, as it timed out for at least the R15B01
job of the timeout patch merge:
https://travis-ci.org/rebar/rebar/builds/15051701
https://travis-ci.org/rebar/rebar/jobs/15051703
|
| | |
|
| |
|
|
|
| |
The current default (30s) causes inttest/rgen1 to timeout too often. Add
retest.config to double the timeout.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directives
Rebar, when it encounters a lib_dir directive, caches the current code
path, adds the libdir(s) and returns the cached copy of the path. When
rebar has finished processing that directory, it restores the cached
path. This is problematic in the below scenario:
/(lib_dir)->G
A -> B -> C -> D -> E
\-> F -> D -> E
When rebar is finished processing B, it restores the code path to what
it was before it processed B, removing C, D, E and G from the code path.
This means when it comes to process F, neither D or E are in the code
path, so any header includes, rebar plugins or parse transforms will not
be in the code path. Without the lib_dir directive, rebar does no code
path cleanups, so everything works fine.
This change makes rebar only remove the explicit lib_dir code paths it
added and adds an inttest that replicates the above scenario.
|
| | |
|
| | |
|
| |\
| |
| | |
Fix searching for plugins
|
| | |
| |
| |
| |
| | |
If a plugin is in a dependency, rebar didn't search for it carefully
enough.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
The DirRef in the spec file is relative to the directory where the spec
file is located. ct2_rt was erroneously copying the spec file to test/.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Avoid overwriting custom config (passed with -C) when we are processing
the base_dir in rebar_core.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Currently the --config switch does not work because when loading
a new rebar config the global setting is ignored for all paths.
This patch provides a check when loading new rebar config to see
whether or not the current config path matches the `base_dir` set in
global conf, which produces the expected behaviour.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds support for executing ct test runs based on test
specificiations, which was missing previously. The rebar_ct module
now looks for any number of files with a name ending in `test.spec`
and if it finds one or more, passes these after the `-spec` argument
to ct_run instead of explicitly configuring the config, user config
and coverage config variables.
When no specifications are found, then the module behaves as it did
before this change, and both the ct1 and (new) ct2 integration tests
appear to show this is a backwards compatible patch.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
--HG--
extra : rebase_source : 5035f025b5873cedfb67e42159c5ce95b07c198d
|
| |
|
|
|
| |
--HG--
extra : rebase_source : cd143fdf55773dcfbeeda687570b226def42e4f5
|
| |
|
|
|
| |
--HG--
extra : rebase_source : c0bfcfbbbca005eee2a3434cbe25494399b07532
|
| |
|
|
|
| |
--HG--
extra : rebase_source : 1998dc102f89c3c809d5146c800218b5c5b6cba9
|
| |
|
|
|
|
|
| |
tdeps1_rt to use it
--HG--
extra : rebase_source : 010907d47b360288825cb9c841d62450700be225
|
| | |
|
| | |
|
| |
|
