| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \
| | |
| | | |
Fix ordering of overlays and overlay vars in Relx
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Specifically, this impacts profiles. It appears that relx as a whole
requires its configuration to be merged in one tuple order (New takes
precedence over Old), whereas the overlays require the opposite (Old
takes precedence over New) since the operation order on disk is
important to work well.
This patch reorders overlay values such that the overlay of a profile
takes place *after* the basic overlay, ensuring that the profile actions
take place after the basic ones; this allows profiles to properly
overwrite files as expected (see #1609)
This is done while adequately maintaining the order of operations that
were required as part of #1563
Overlay vars of profiles are also checked to be working fine, along with
a test.
This fixes #1247 and #1609
|
| |\ \ \
| | | |
| | | | |
Add an alias of 'release' template as 'umbrella'
|
| | | |/
| |/|
| | |
| | |
| | |
| | | |
Gets in line with more common usage of the wording, as discussed in
issue #1421 and
https://www.reddit.com/r/erlang/comments/6sd01p/help_terribly_frustrated_with_the_erlang_build/
|
| |\ \ \
| | | |
| | | | |
Remove duplicate ebins from escripts
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
During the building of escripts, multiple passes are done. Two of them
may end up duplicating content: one that gathers all of the beam files
that will be needed for the app to work, and a second one that goes over
the ebin/ directory of the root application to grab all the stuff in
there, prior to the run.
This allows to grab whatever could be required for runtime without
breaking the rest (or so I think), and sticks them at the front of the
archive, where it needs to sit for things to work fine.
Whenever the ebin/ directory contains a pre-compile .beam file, it gets
fetched both from the first pass described and the latter one. This
results in duplicate entries in the resulting zip files used for the
escript and makes the executable larger than it needs to be.
The patch is a simple 1:1 removal of duplicate values. Since
large pre-populated ebin/ directories are pretty rare, this should not
be too costly for the vast majority of users.
Fixes #1577
|
| |\ \ \
| |_|/
|/| | |
Fix total coverage
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | | |
Fix recursive profile merging, particularly for umbrella apps
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a config file exists at the root of a project, defines a given
configuration value for a given profile, and that a sub-application
(umbrella app) also has the same profile defined with the same key (but
different values), the configuration values of the sub-application's
profile would get silently dropped.
The problem being that when the function to merge profiles is applied
recursively, it is applied to each profile (so it will merge on the keys
test, prod, etc.) rather than to each of the values of each profile.
This patch reworks the profile merging so that the current behaviour is
respected overall (a profile cannot be cancelled by a subdep's
non-existant profile since its value should have been ignored), but
ensures that sub-deps' profiles are otherwise applied recursively with
the proper rules:
- dependencies favor prior values
- plugins favor new values
- erl_first_files combine the lists
- relx uses the tuple merge algorithm
- erl_opts has its own custom merge as well
- otherwise the new value takes precedence
A test has also been added.
There is a risk of breakage in some applications that may have relied on
the buggy behaviour to work, though at this time we are aware of none of
them.
|
| |\ \
| |/
|/| |
appveyor configuration to build on 15.3.1, 17.5, 18.3 and 19.2
|
| | | |
|
| | |
| |
| |
| | |
16.x is not available on chocolatey
|
| |\ \
| | |
| | | |
Allow top-level apps to take precedence over deps
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The use case has been described in issue #1478 where a local application
can exist while being declared as a dependency as well. This allows, for
example, to work on a release where all applications may require to be
published independently, or to provide some form of 'vendoring' with a
local app.
The fix is done by decoupling the dependency source resolution form the
dependency parsing. The reason for this being that the discovery phase
needs to parse apps for their top-level deps, and dep installation needs
to resolve the packages with accuracy. In the current implementation,
both code paths call to the same function.
This patch splits up the precise discovery and makes it happen *only*
when installing dependencies, and only if a top-level app does not
already define the application needing resolving.
One weakness of this fix is that it necessarily breaks cycle detection
in dependencies that involve a root application depending on itself
since its own version as a dep will not be expanded. There appears to be
no possible way to prevent this, but should be rare enough to be worth
the tradeoff for the common case.
|
| |\ \ \
| | | |
| | | | |
Bump cth_readable to 1.3.0: shows test groups
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
Unicode support in all the places
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is done through 3 main change groups:
- replacing `~s` by `~ts` in format strings, so that strings that
contain unicode are properly printed rather than crashing
- adding the `unicode` argument to all function of the `re` module to
ensure transformations on strings containing unicode data are valid
instead of crashing (see issue #1302)
- replacing `ec_cnv:to_binary/1` and `ec_cnv:to_list/1` with matching
functions in `rebar_utils`.
The last point has been done, rather than modifying and updating erlware
commons, because binary and list conversions can be a contentious
subject. For example, if what is being handled is actually bytes from a
given binary stream, then forcing a byte-oriented interpretation of the
data can corrupt it. As such, it does not appear safe to modify erlware
commons' conversion functions since it may not be safe for all its
users.
Instead, rebar3 reimplements a subset of them (only converting
atoms and chardata, ignoring numbers) with the explicit purpose of
handling unicode string data.
Tests were left as unchanged as possible. This may impact the ability to
run rebar3's own suites in a unicode path, but respects a principle of
least change for such a large patch.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Upgrade certifi & ssl_verify_fun dependencies
|
| | | | | | | |
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Get more up-to-date root certs. This was blocked for a while because
certifi wouldn't build on windows, but this is now fixed, with minimal
changes to the use case -- only a small change in the bootstrap script
is required.
The new certifi lib is also a few megabytes lighter than before, which
is good for rebar3.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Ignore IntelliJ IDEA file
|
| | | | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
g-andrade/fix/avoid_crashing_xref_upon_stripped_modules
Avoid xref crash upon undefined functions in modules without debug_info
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
modules
This can be reproduced by running xref analysis against a rebar3
plugin project which doesn't list rebar3 as an explicit dependency
-- calls to certain bundled modules ('rebar_state', 'rebar_api',
'ec_cnv', ...) will result in a failed pattern match as these modules
appear to have had their abstract code stripped.
|
| |\ \ \ \
| | | | |
| | | | | |
Fix cleanup_code_path for xref compile hook
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | | |
Edoc config error
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
be a little smarter when generating edocs; loof for some
sort of doc path and then replace w/e was there with the
updated doc paths
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
upgrade relx
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | | |
add compile_only option to ct provider
|
| | | | | | |
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | | |
recompile only if new option effects code generation
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
drop warnings for `export_all` in test profile
|
| |/ / / / |
|
| |\ \ \ \
| |/ / /
|/| | | |
update meck for otp20
|
| |/ / / |
|
| |\ \ \
| | | |
| | | | |
Bare compiler: support multiple paths wildcards.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Similarly to PATH env variable, this allows to pass paths to bare
compiler which do not fit nicely into a single wildcard structure.
Colon (":") is used as separator.
This provides more flexibility when rebar is run in offline/hermetic
environment, e.g. #958 and #1281.
|
| |\ \ \
| | | |
| | | | |
Rebar3 shell supports booting applications with type 'none'
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I noticed this when trying to include entop in a release. Entop uses
cecho which takes over the terminal, so you do not want it loaded or
started. According to http://erlang.org/doc/man/rel.html, when you
specify a Type of none it should not load or start, but the code for
it's modules should be loaded. This patch ensures the code is not
loaded or started, but doesn't do anything with the code paths.
At the very least this allows me to start a shell in the case where
I have an application of type none, and the application is neither
loaded nor started.
|
