RFR: JDK-8074859 Turn on warnings as error

[Erik Joelsson]

Looks good.

/Erik

On 2015-05-08 09:57, Magnus Ihse Bursie wrote:
> On 2015-04-20 09:02, Erik Joelsson wrote:
>> Looks good to me.
> Thanks Erik.
>
> Unfortunately, I never got round to pushing this. In the meantime, the 
> codebase evolved, and I had to add a couple of more disabled warnings. 
> I also modified the help text on a failed build slightly.
>
> Here's the updated webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors/webrev.01
>
> /Magnus
>
>
>>
>> /Erik
>>
>> On 2015-04-17 14:52, Magnus Ihse Bursie wrote:
>>> With JDK-8074096, the number of warnings in the product was reduced 
>>> to a minimum. This enables the next step, which is turning on the 
>>> respective compiler flags that turns warnings into errors. In the 
>>> long run, this is the only way to keep the warnings from creeping back.
>>>
>>> Even with JDK-8074096, the product does not build 100% warning free. 
>>> This is due to some warnings that cannot be disabled, or (in one 
>>> case) where C and C++ code is mixed, and warnings for both languages 
>>> cannot be used. A system similar to the one introduced in 
>>> JDK-8074096 is therefore needed, in which individual libraries can 
>>> be exempted from this flag, until such warnings are fixed. A library 
>>> can thus disable warnings as errors with WARNINGS_AS_ERRORS := 
>>> false, or (better) use a toolchain-specific version, e.g 
>>> WARNINGS_AS_ERRORS_gcc := false. This is intended as a temporary 
>>> measure, though. The long-term solution is reasonably to fix the 
>>> warnings and remove that argument.
>>>
>>> Also, different versions of compilers can generate a different set 
>>> of warnings. It is therefore necessary to be able to turn off this 
>>> globally. Therefor a new flag for configure is introduced: 
>>> --disable-warnings-as-errors.
>>>
>>> While the code compiles without errors on the build systems used 
>>> internally at Oracle, this might not be the case on other 
>>> combinations of operating system versions and toolchain versions. To 
>>> facilitate for unexpecting developers, a help message is added if 
>>> the build fails, that suggests using --disable-warnings-as-errors. 
>>> This solution was chosen as a compromise between the "hard core" 
>>> solution of turning on warnings as errors by default for anyone, and 
>>> the cowar... erm, conservative solution of checking if the compiler 
>>> versions exactly match what's used inside Oracle (and therefore 
>>> regularly tested), and only turn it on in that case.
>>>
>>> Similarly to JDK-8074096, I intend to file follow-up bugs for each 
>>> individual library that got a WARNINGS_AS_ERRORS_* := false.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859
>>> WebRev for top: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01
>>> WebRev for jdk: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01
>>>
>>> Some comments:
>>>
>>> * I needed to add a few more DISABLED_WARNINGS. For windows, this is 
>>> most likely due to the recent compiler change. For other libraries, 
>>> I'm not sure, but it might well be the result of recent changes that 
>>> has introduced new warnings. If so, it highlights the need of this 
>>> patch to keep the build warning free.
>>>
>>> * For a few libraries and toolchains, there is *both* 
>>> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is 
>>> the case if not all warnings are possible to disable.
>>>
>>> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This 
>>> is included in our JDK LDFLAGS, so it should not be set separately, 
>>> and definitely not as CFLAGS. (This caused compiler warnings, which 
>>> now turned into errors.) However, a more suitable long-term solution 
>>> is probably to move the knowledge of how to create shared libraries 
>>> more specifically into SetupNativeCompilation, and not set it as 
>>> part of the JDK flags.
>>>
>>> /Magnus
>>
>