[erlang-questions] Deprecation warnings: OTP20 and OTP21 compatible code

[Fred Hebert]

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:

{overrides, [
    {del, [
        {erl_opts, [warning_as_errors]}
    ]}
]}

and would let you instantly remove the option from all dependencies 
rather than having to go through the override pattern Jesper has shown 
here.

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 
there.

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.