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

[Erik Joelsson]

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.

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.

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.

/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
>>
>