| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current rebar3 uses debug_info rules where debug_info is added by
default, and no_debug_info prevents the default from being added, and
removes any explicit debug_info, if any. The problem is that if
'no_debug_info' is anywhere in the config for a run, it cannot be
removed even with other profiles. additionally, no_debug_info ignores
special tuples like {debug_info, {Mod, Data}} and {debug_info_key, Key},
which can be used to add debug info and encrypt it (in lieu of plain
debug_info) respectively.
This patch makes it so that the following rules are in place:
- the last option seen takes priority, allowing profile overrides by
the ordering rules the compiler expects
- the overriden options shall be explicitly deleted to avoid confusing
the compiler
- any option related to debug info seen last cancels any no_debug_info
that preceded it
- any no_debug_info option seen last cancels all of the other
debug_info options
- if debug_info is seen last, it cancels out {debug_info_key, Key}
- if {debug_info_key, Key} is seen last, it cancels out debug_info
- All other options are left untouched in that context (defines can
still be expanded and so on)
This should allow proper profile rules to be followed. Note that erl_opt
profile merging puts precedence on the *last* element of a list, to
match the compiler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The order of the files listed in "erl_files_first" option is
important and should not be sorted. By handling the merge
similarly to mib_files_first, the sort order is preserved.
|
| |
|
|
|
|
| |
Ensures merged compiler options end up in the correct order to maintain profile precedence.
Moves the merge functionality from rebar_opts:merge_opts/2 to a standalone function to ease extension and debugging.
|
| |
|
|
|
|
|
|
|
|
|
| |
Relx config need new values at the end of the list and
profile additions prepended. So now in apply_profile in
the case it is a relx config we prepend the config list.
This does, however, mean that a profile release can not
'extend' a release defined in the default profile since
the one being extended would have its definition after
the profile release and thus relx would not be able to
use its values for extending.
|
| | |
|
| |
|
