<div dir="ltr"><div>For a larger project, I stumbled into the following while trying to build it on OTP-21.0-rc2-69-g9ae2044073:</div><div><br></div><div>* `erlexec` sets `warnings_as_errors` which fails due to `erlang:get_stacktrace/0`<br>* `meck` sets `warnings_as_errors` which fails due to `erlang:get_stacktrace/0`<br>* `ranch_proxy_protocol` sets `warnings as errors which fails due to `ssl:ssl_accept/3`<br>* `jose` sets `warnings_as_errors` which fails due to `erlang:get_stacktrace/0`<br>* `cowboy_cors` sets `warnings_as_errors` which fails due to `erlang:get_stacktrace/0`<br></div><div><br></div><div>In effect, the warnings_as_errors is now a useless option on any system which wants an upgrade-path from 20 to 21. If you start using the new syntax straight away, you lock out users so they can't use 20 anymore, and in any software project, some system has to support multiple versions in order to do code upgrade[0].</div><div><br></div><div>Current fix for the above is to use rebar3's overrides:</div><div><br></div><div>{overrides,<br> [{override, erlexec, [{erl_opts, [debug_info]}]},<br> {override, ranch_proxy_protocol, [{erl_opts, [debug_info]}]},<br> {override, cowboy_cors, [{erl_opts, [debug_info]}]},<br> {override, jose, [{erl_opts, [debug_info]}]}, <br> {override, meck, [{erl_opts, [debug_info]}]}]<br>}.<br></div><div><br></div><div>which plugs the hole for now. But I'm a bit hesitant to just write those projects since I'm not sure I have a good, easily implemented transition path here. I think one might be able to use a bit of macro-magic to accept the particular deprecation warning on 21 (only!) as not-an-error-and-intended-for-now, so one can postpone the 21 upgrade a bit in the software.</div><div><br></div><div>NOTE: This isn't a problem in fully vendored software where you control everything. You can simply define when you upgrade and handle all dependencies directly. But in a setting where other people rely on your libraries, it is usually a bit more flexibile to allow them the ability to run on the current version as well as the version one level back.<br></div><div><br></div><div>[0] Note this is somewhat similar to a code_change/3: Some function needs to understand how to transform old data to new data and thus work with both versions for a while.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 5, 2018 at 2:22 PM Danil Zagoskin <<a href="mailto:z@gosk.in">z@gosk.in</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<div><br></div><div>This is a shout of pain we got while preparing our project for upcoming OTP release.<br><div><br></div><div>The problem:</div><div> * We compile our code for production using warnings_as_errors option. This helps us to keep the code tidy.</div><div> * OTP21 deprecates some functions (erlang:get_stacktrace/0, ssl:ssl_accept/0, may be more)</div><div> * OTP20 does not support new API (catch C:R:S, ssl:handshake/2)<br><br>So, to be able to go with both OTP20 and OTP21, we need some hacks.</div><div><br></div><div>First thought: let's pass {nowarn_deprecated_function, [...]} with Emakefile, letting old code</div><div>compile smootly in newer OTP.</div><div>But that cannot be done — this option is only recognized when given in files.<br><br>Second thought: OK, let's just add this option to all affected files.</div><div>But "Warning: erlang:get_stacktrace/0 is not a deprecated function"</div><div><br></div><div>So, we needed to implement some preprocessor logic which adds nowarn only when compiling with OTP21.</div><div>Luckily, there is a OTP_RELEASE var defined in OTP21:</div><div><div>-ifdef(OTP_RELEASE).</div><div>-compile({nowarn_deprecated_function, [{erlang, get_stacktrace, 0}]}).<br></div><div>-endif.<br></div></div><div><br></div><div>Adding that to tens of files (large project, lots of dependencies in-tree) seemed too ugly,</div><div>so we implemented a parse_transform which can be added to Emakefile.</div><div><br></div><div>Parse transform itself: <a href="https://gist.github.com/stolen/6a55221ffb906bde712cd939a729718d" target="_blank">https://gist.github.com/stolen/6a55221ffb906bde712cd939a729718d</a></div><div><div><br></div>-- <br><div class="m_4906929211316985214gmail_signature"><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></div></div></div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>