<AWT Dev> RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

[Phil Race]

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 
source libraries
and it may not always be possible to convince upstream to change their code.

-phil.


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 
>> recompiled.
> 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.
>
> -Alan