RFR: JDK-8074859 Turn on warnings as error
Erik Joelsson
erik.joelsson at oracle.com
Mon Apr 20 07:02:13 UTC 2015
Looks good to me.
/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
More information about the build-dev
mailing list