| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
When rebar.config contains a `escript_main_app` option, but the
specified app doesn't exist in the build directory, print an error.
|
| |
|
| |
|
| |
|
|\
| |
| | |
lock file contains expected hash for pkg dependencies
|
| |
| |
| |
| | |
- also making sure unlocking works fine
|
| |
| |
| |
| |
| | |
Tests have broken as locks were expanded and auto-filled newer versions
of lockfiles. This fixes them back.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- the internal representation for package locks moves from `{Name, {pkg,
PkgName, Vsn}, Lvl}` to `{Name, {pkg, PkgName, Vsn, Hash}, Lvl}`
- the internal representation for packages moves from `{pkg, PkgName,
Vsn}` to `{pkg, PkgName, Vsn, Hash}`
- the hash can be `undefined`, meaning no check will be done
- no checking is done yet.
|
| |
| |
| |
| |
| |
| |
| |
| | |
changed include files were not properly picked up by `erlc_compiler`
in cases where they were in directories relative to the application
source and not the current working dir of rebar3
fixes #1199
|
|\ \
| | |
| | | |
REBAR-1184 always recompile if `ERL_COMPILER_OPTIONS` env var is set
|
| | | |
|
| | |
| | |
| | |
| | | |
partially addresses #1184
|
|\ \ \
| | | |
| | | | |
Compiler source paths in output are now relative
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|