<Sound Dev> <AWT Dev> RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis
philip.race at oracle.com
Wed Mar 4 21:31:34 UTC 2015
I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.
I do want to mention that some libs like liblcms are 3rd party open
and it may not always be possible to convince upstream to change their code.
On 03/04/2015 08:30 AM, Alan Bateman wrote:
> On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
>> I believe all warnings are important to check! Unfortunately, this
>> has not been done for a lot of warnings for a lot of time. :(
> Right, although in the past we had some areas close to be cleared of
> warnings, it's just that we didn't keep up the effort and of course
> the compilers get more pedantic with each version.
>> With this framework, it is simple to enable a single warning,
>> recompile and see the effect. Hopefully this lowers the threshold far
>> enough so that all warnings are given proper attention. The
>> incremental build functionality will come in very handy. Just by
>> simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a
>> library and running "make" again, only the files affected will be
> Yes, it looks easy to maintain.
>> I can easily paste in what warning categories are disabled for a
>> specific library, yes.
>> However, if you are asking me to build each library, individually,
>> with warnings re-enabled, and pasting the output, I'd rather not.
>> That would be a lot of work, to detangle the output of each
>> individual library.
> I'm not asking that, it would be too much work. Maybe it's worth
> saving the logs somewhere so that you can point the bugs at it. It
> would also be useful for the bugs to point to your change sets (when
> they are pushed) so that it's obvious which make files were changed to
> silence the warnings.
More information about the sound-dev