This would cause crashes on linux and force people to have a src_dirs
config that is strictly matching what is on the file system rather than
acting as a specification of those that are valid.
To compare, if lib_dirs worked the same, then any repo that did not both
have apps/ and lib/ would crash, as the spec mentions both options as
valid.
Since packages store etags on disk directly, the local install feature
can no longer depend on this; we instead port the etag feature back to
local providers only.
This patch makes it so that whenever the rebar3 shell has a new
configuration for an application that is already running and would be
restarted (without risking the stability of the node or functionality of
rebar_agent), we stop and restart the app.
When adding the 'TEST' macro to the test profile, we mistakenly sourced
the erl_opts values from the base profile rather than the test profile
itself.
This means that in cases where the base profile set an option such as
'no_debug_info' and a profile overrode it with 'debug_info', the default
options would get injected within the test profile, and broke the
precedence rules, yielding incompatible values.
This patch fixes things by adding the macro to the values sourced from
the test profile itself, fixing the issue.
This will at least display the script that failed with the stacktrace
before failing as usual, but without altering the return value.
This should make the common failure path more user-friendly without
breaking any existing behaviour that may have relied on the script file
working. If there's any unexpected side-effect, it will be visual only
rather than blocking full builds if ?ABORT were used.
Some still remain from erl_type calls from Dialyzer, but most of them
are handled.
Decided to just ignore rebar_alias since playing with the type specs of
abstract code format is just a nightmare and hard to do cross-versions I
guess.
We got funny interactions since PR #1656:
- the last `debug_info`-related option seen in a list of options after
profile merge is kept, allowing later profiles from overtaking earlier
ones
- if you go `rebar3 as a,b,c compile`, the options from profile A come
before B, which come before C, so C's options win
- overrides are applied in order of profile as well, giving a priority
to a later profile than an earlier one
- The values in overrides are prepended rather than suffixed to the
existing list
- this means if we have to overrides adding options, such as `default`
adding `no_debug_info', and `dialyze` adding `debug_info`, the
results are `[debug_info]` as `dialyze` is applied first, and then
`[no_debug_info, debug_info]` as `default` overrides are applied
- the final result is `no_debug_info` always winning when erl_opts are
overriden specifically.
only `debug_info` options are going to suffer this, and in the context of
overrides. Other `erl_opts` should be fine. I'm not sure how that can be
fixed at all.
In the meanwhile, we can add support back while leaving the default to
not having debug information. This is done by:
- moving all `no_debug_info` options to the `prod` profile
- forcing `prod` to be called by `./bootstrap` so that most people keep
getting no debug info
- anyone calling `rebar3 clean -a` and then rebuilding with `rebar3
escriptize` (i.e. rebar3 devs) get debug info going
This is up for review and discussion.
Fred Hebert
Dmitry
Laszlo Toth