| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This is necessary in order to automatically get the testspec included
as an artifact (i.e. copied to the _build dir) in the case when it is
stored in another directory than 'test'.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: option 'spec' is not specifically handled when merging options
from the command line with options from rebar.config. Due to this, if
the config specifies a 'spec', then this will take precedence over any
'dir' and/or 'suite' on the command line.
This commit takes special care of all options that can be used to
select tests - meaning that if any of the options 'spec', 'dir',
'suite', 'group' or 'case' are specified on the command line, then all
'spec', 'dir', 'suite', 'group' and 'case' options in rebar.config
will be ignored.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
init_config, added unit tests
|
|
|
|
|
|
|
|
|
|
|
|
| |
The option {recursive,boolean()} can now be set pr directory in
'src_dirs' and 'extra_src_dirs', and on top level in the new
'erlc_compiler' option. Example config:
{erlc_compiler,[{recursive,false}]}.
{src_dirs,[{"src",[{recursive,true}]}]}.
This will cause recursive compilation within the "src" directory, but
not in any other directoires.
|
|
|
|
|
|
|
| |
* exclude_apps - never use applications for PLT/analysis
* base_plt_mods - add modules to base PLT (overrules exclude_apps)
* plt_extra_mods - add modules to PLT (overrules exclude_apps)
* exclude_mods - never use modules for PLT/analysis (overrules all)
|
|
|
|
|
|
| |
`rebar3 ct --spec foo.spec,bar.spec,baz.spec` now works
also added support for the `join_specs` flag on the command line
|
|
|
|
| |
checks on hd(...) and so on could not handle empty lists
|
|\
| |
| | |
Properly support package aliasing and alt names
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds tracking of package hash in the in-memory index rather than
the current `undefined' values.
According to the test added, this is not necessary for transitive
package dep hash chcking, but does result in a more complete index search
result when doing app lookups, and could yield some optimizations on
hash checks by checking from the index structure before fetching a package.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Aliasing only had a bit of ad-hoc support in rebar3, and various issues
have encountered problems related to the package names not mapping
properly with the application name. One such issue is
https://github.com/erlang/rebar3/issues/1290
The problem has been hard to find because it only impacts transitive
dependencies (not top-level ones) of other packages. The root cause for
this is that the application name was not being tracked by rebar3's internal
index, only the package name and its version were.
When a given application was a package app, the data for the application
name would be reconstructed from the lock file, but only if it were a
top-level app or a dependency of a source application where parsing the
lock file is necessary to know what comes next.
When a transitive dependency of a package dependency was fetched, we
instead read its dependencies directly from the in-memory package index
within rebar3. This caused us to only read the package name and version,
and lost all information regarding application name. This worked fine
for most cases since for the vast majority of packages, the package name
matches the app name, but failed for all aliases, which would then be
moved to directories that wouldn't match the app name.
This in turn broke some aspects of code analysis (in Dialyzer), or other
functionality relying on static paths, such as including .hrl files from
dependencies.
This patch reformats the internal storage format of dependencies to
align with the internal one used by rebar3, so that the app name can be
carried along with the package name and its version.
The fix can only work once `rebar3 update` is called so the index is
rebuilt internally, and will the file cached on disk will be
incompatible with older rebar3 versions.
Currently, the following is not covered:
- Tests
- Including the package hashes of dependencies so they may match what
is in a lock file -- they're being `undefined` instead, which may
break some lookups. The previous format did not lend itself to hashing
in the same way, and it is possible transitive deps were not being
tracked properly, or worked by respecting the current package hierarchy.
This will require further analysis
For now this commit can allow reviewing and discussion.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an include file is set in a private path (i.e. src/), the rebar3
compiler would not add them to the {i, Path} params -- only include/ and
the project root were being added.
This meant that when some extra source directories were added to the
compile job, such as test/ when running under the test profile, the
private include paths could not be shared with the test module.
This patch fixes the issues (and adds tests) for such a specific case by
adding all the configured include paths to the {i, Path} erl_opts
arguments, yielding successful compile runs.
|
|/ |
|
|
|
|
|
|
|
|
| |
{`eunit_test_regex`, Regex}` will use the supplied `Regex` instead of
the default to locate tests in test dirs. note this matches only the
filename, not the path. the regex is applied to all test dirs, recursively
fixes #1331
|
|
|
|
|
|
|
|
|
| |
there's no way to detect which files actually rely on a parse transform
passed to the compiler via the options (as opposed to `-compile(..)`
so if any parse transforms are in modules that need recompiling just
recompile the world
fixes #1328
|
|
|
|
|
|
|
| |
In some cases, mv will throw a warning, while still moving the files
correctly and returning a 0 return code:
"mv: can't preserve ownership of ... Permission denied".
|
| |
|
|
|
|
| |
`cover:analyse/0` didn't exist pre-otp18
|
|
|
|
|
| |
provider chains like `eunit, ct, proper` from misreporting cover
stats from providers later in the sequence
|
| |
|
| |
|
|
|
|
|
| |
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.
|