RFR: JDK-8210988 Improved handling of compiler warnings in the build

[Magnus Ihse Bursie]

On 2018-09-21 18:27, Erik Joelsson wrote:
> Hello,
>
> I sort of understand why you want to setup LDFLAGS_WARNINGS_ARE_ERRORS 
> together with cflags, but it is a bit weird when we have a file 
> specific for ldflags.
Agree, it does not belong there.
>
> In NativeCompilation.gmk, why do we suddenly need to combine stdout 
> and stderr for the microsoft compiler? I remember working hard to keep 
> the streams separated through the logging framework. If we scrap that, 
> a lot of things can be made much simpler.
I honestly don't remember. This patch is extracted from a sandbox that 
I've been working with since before summer. I don't remember anymore 
what prompted me to add it. I've removed it.
> As a general rule, the more specific set of flags should be added 
> after global flags so precedence is kept correct. It probably doesn't 
> matter much here, but I think it's good to stick to that standard. In 
> this case the library specific flags should be added after the global 
> flags.
Well, since the disabled flags just accumulate, it really don't matter, 
but sure, it's a good standard to keep.

Updated webrev:

http://cr.openjdk.java.net/~ihse/JDK-8210988-improved-warning-flags-handling/webrev.03

/Magnus

>
> /Erik
>
> On 2018-09-21 00:20, Magnus Ihse Bursie wrote:
>> On 2018-09-21 01:41, Magnus Ihse Bursie wrote:
>>> This is the first part towards a better framework in the build for 
>>> handling compiler warnings. The basic idea is that we should have 
>>> consistent way for all compilers to:
>>>
>>> 1) enable all (relevant) warnings
>>>
>>> 2) disable individual warnings, on a global scale (if 1 enables too 
>>> much)
>>>
>>> In particular, this means unifying the basic set of enabled warnings 
>>> between hotspot and the JDK native libraries.
>>>
>>> From that starting point, warnings can be disabled on a per-library 
>>> fashion, if it does not make sense for that specific library. (Like 
>>> how it's done today, but more consistently performed.)
>>>
>>> This first part will just put most of the infrastructure in place, 
>>> and strives to keep exactly the same warnings enabled or disabled 
>>> for all code.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210988
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8210988-improved-warning-flags-handling/webrev.01
>>
>> Here is an updated webrev that does not break zero:
>> http://cr.openjdk.java.net/~ihse/JDK-8210988-improved-warning-flags-handling/webrev.02 
>>
>>
>> /Magnus
>>
>>>
>>> /Magnus
>>>
>>
>