[erlang-questions] Deprecation warnings: OTP20 and OTP21 compatible code
Wed Jun 6 13:18:58 CEST 2018
On 06/06, Loïc Hoguin wrote:
>It's worth noting that you did not have an issue with Cowboy, Ranch
>and friends. That's because the default policy in Erlang.mk is to NOT
>use warnings_as_errors for dependencies (and as a result this option
>is not included in the generated rebar.config).
>This saves a lot of headaches. erlang:get_stacktrace/0 is notable in
>how widely used it is but issues with warnings_as_error have always
>existed for as long as I've been doing Erlang. Tools should really
>have a saner default policy for this. The build shouldn't break for
>your users just because a new warning was introduced.
Rebar3 leaves the warnings that libs put for themselves there.
There's a PR currently going about adding a 'del' override, which would
let someone remove the option by specifying:
and would let you instantly remove the option from all dependencies
rather than having to go through the override pattern Jesper has shown
If/Once merged, it would help address the problem. I'm a bit hesitant to
go and disable some options _by default_ when library authors have set
them there for a reason.
Now for the case of get_stacktrace(), macros are pretty much the only
way we've found to deal with this. I'm a bit disappointed that the issue
where the change was made had this debated a long time
(https://github.com/erlang/otp/pull/1783) but the changes to the
language have been railroaded without regards to community complaints
Rebar3 ended up going with a macro-heavy approach suggested by @okeuday
in here: https://github.com/erlang/rebar3/pull/1773/files
Libraries like GPB had to resort to more trickery since the files can be
static and embedded in other projects without pre-defined macros: https://github.com/tomas-abrahamsson/gpb/issues/134
This ended up being a big pain in the ass for a lot of people due to the
very aggressive deprecation schedule.
More information about the erlang-questions