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

[Erik Joelsson]

Looks good, thanks!

/Erik


On 2018-09-21 11:08, Magnus Ihse Bursie wrote:
> 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
>>>>
>>>
>>
>