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
