| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
By default rebar3 displays compiler sources as absolute paths in their
original location, which is under the build dir.
This change introduces an option 'compiler_source_format' to format
sources in two alternative ways:
relative
absolute
When either 'relative' or 'absolute' are specified, the file is
resolved to its original location when it is a link. When 'relative'
is specified, the path is displayed relative to the current working
directory. When 'absolute' is specified, the path is absolute.
The default value is 'unchaged' which leaves the compiler source
unchanged.
This is arguably too flexible as I suspect most people would opt for
'relative' all the time - it's the most compact representation of the
file and is sufficient to find the source given cwd. The change
however is meant to introduce the change gradually, preserving
existing behavior and giving users a choice for formats.
In time perhaps the default can be changed to 'relative' - but still
allowing users to revert to the other two options ('absolutel' and
'unchanged') as needed.
|
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | | |
- The configured stuff in rebar3 takes precedence over the ENV
- The env is then chosen
|
| |/
|/|
| |
| |
| |
| |
| | |
When the operation for an unlock takes place in the config of a umbrella
application, the `unlock' provider does not see the dependency in the
`deps' value of the config (since it only includes the deps at the root
of the project) and ignores these.
|
| |
| |
| |
| | |
don't bother checking the profile in the path to the data dir
|
|/
|
|
| |
closes #1057 and #1179
|
|\
| |
| | |
Allows overwrite default cache dir using REBAR_CACHE_DIR
|
| |
| |
| |
| |
| | |
Instead of reading every time that rebar_dir:global_cache_dir/1 is
called
|
| | |
|
| |
| |
| |
| |
| | |
Allows overwrite the default cache directory using the environment
variable REBAR_CACHE_DIR.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit moves the handling of distribution config and starting out
of rebar_prv_shell and into rebar_dist_utils. The module is able to
handle standard config options and boot a distributed node mode. This
could be used in plugins (once it is exposed) and other providers like
CT.
Configuration is also expanded so that options like:
{dist, [{sname, atom()}, {name, atom()}, {setcookie, term()}]}
can be used and will be handled as a default. The config handler
supports similar terms from the command line being parsed in if the
calling provider supports them.
A test suite is added for configuration handling.
|
|
|
|
| |
add definition of 'COMMON_TEST' macro to eunit provider
|
|
|
|
| |
This reverts commit 4c32c52b557c66ac6e6764efb1ed9135c00a3c20.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The idea is that given we accept arbitrary config items for CT, we
should similarly be able to pass unsupported options and keep things
running.
However for unsupported options, a warning is very useful to have.
|
|\
| |
| | |
add support for common tests `include` flag
|
| | |
|
|\ \
| | |
| | | |
error on a cover spec in ct_opts
|
| | | |
|
| |/ |
|
|/ |
|
|\
| |
| | |
Hex improvements
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add more version constraints
Allow for any number of whitespaces after compairison opperator
Improve updating and error printing
Fix failing tests
|
|\ \
| |/
|/| |
add project_providers after initing default providers but allow overrides
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes to how hex or packages may work in the future will necessarily
bring changes to the format of lock files.
This commit adds an optional framing for future lock files of the form:
{Version, LockList}.
<Whatever consultable attributes>
This format is supported such as the LockList is the current lockfile
contents, and will never have more information than it currently does.
Attributes can be whatever and are currently undefined.
Rebar copies will be able to:
- Keep using the core locklist (which avoids breaking the last year or
so of community libraries using rebar3)
- Warn when it runs an outdated copy in comparison to the lock file
- Automatically rewrite lock files in the format it supports
- Augment or parse files in a version-specific manner.
This changes the usage interface slightly, but is backwards *and*
forwards compatible.
|
|\
| |
| | |
Add test case for relx overlay vars
|
| |
| |
| |
| |
| | |
Makes use of several var types: integers,
strings, binaries, binary strings and tuples.
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
Several projects use an include path relative
to the project's root.
file:compile will look in three places for the include
files:
The current working directory
The directory where the module is being compiled
The directories given by the include option
|
|\
| |
| | |
add profile option to clean task
|
| | |
|
|/
|
|
|
| |
this ONLY attempts to deduplicate test sets that are generated by
rebar in the absence of any user specified tests
|
| |
|
| |
|
|\
| |
| | |
only apply default and prod profile to dependencies
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- robocopying a directory into another directory recursively expects the
directory name to be properly mapped onto the destination, otherwise
all the files are copied into the given path. This patches things so
a directory-to-directory robocopy works as expected in a linux mindset
so tests pass
- the test for canonical paths didn't expect a windows environment at
all; the test (and library) is modified to be consistent in that
environment: always with a native format and with proper support of
drive letters.
|
|/ |
|
|\
| |
| | |
allow ct suites to be specified at root of project (or root of app)
|
| | |
|
| |
| |
| |
| | |
this allows repeated test suite names across apps without conflicts
|
| |
| |
| |
| |
| |
| |
| |
| | |
previously rebar3 dropped suites declared at the root of the project (via
`--suite=whatever_SUITE' probably) and warned. this was because the compiler
would recursively copy and compile everything in the directory indicated by
the test suite. this changes the copy mechanism to only copy erl source files
and directories that end with `_SUITE_data' into the `extras' dir in `_build'
|
| | |
|
|\ \
| |/
|/| |
Plugin templates
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This lets a plugin define templates to be loaded:
$ rebar3 new
...
proper (plugin): A basic PropEr suite for an OTP application
...
$ rebar3 new help proper
proper:
plugin template (...)
Description: A basic PropEr suite for an OTP application
Variables:
name="suite" (...)
...
→ rebar3 new proper fakesuite
===> Writing test/prop_fakesuite.erl
In this case, proper is a fake template file I've put by hand in
_build/default/plugins/rebar3_proper/priv/<somename>/, meaning it will
only work as far as it's called from the project's root.
The priority order of plugins is now .config > plugin > built-in, such
that someone could ensure plugins do not crush their own private
templates, but also that custom or plugin templates do overtake built-in
ones. It used to be Built-in > .config only.
Templates are searched for recursively in the priv/ directory of
plugins.
|