RFR: JDK-8198724 Refactor FLAGS handling in configure
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Feb 26 23:40:50 UTC 2018
The current way we're handling FLAGS (CFLAGS/CXXFLAGS, LDFLAGS, etc) is
laden with technical debt. It's a sorry mess, hard to do anything
This is the first step towards a better solution. The main goal is to
have a set of more specific flags, more like how the SYSROOT flags work
today, that can be individually included, instead of a huge CFLAGS_JDKLIB.
To make such a change manageable, this first step will (almost) only
refactor the autoconf code, but will output the same flags in the spec.gmk.
To minimize special cases, I have accepted the following differences:
* On linux/gcc, we will get a -m<bits>, e.g. -m64 always (as on
* On macosx/clang, we will get a -m<bits>, e.g. -m64 always (as on
* On macosx/clang, we will now "hardcode" the max/min version number
* On macosx/clang, the JVM_CFLAGS for the build toolchain will now also
get an -fPIC (this was mysteriously missing before).
* On windows/microsoft, the build toolchain will now get -nologo added
as well, and also -homeparams for debug builds.
* On solaris/solstudio, the JDKEXE flags will now include -errfmt, and
CFLAGS_JDKEXE will include -errtags=yes. The duplication of -errtags=yes
in CXXFLAGS_JDKLIB is removed.
* On solaris/solstudio, we now always use -KPIC as pic flag.
(Previously, we used -xcode=pic32 on sparc, but this is equivalent to
-KPIC, so there's no reason for a special case.)
* On solaris/solstudio, we now use e.g. "-Wc,-Qrm-s" instead of
"-Qoption cg -Qrm-s" for C++ as well as for C code. The two formats are
equivalent (for passing options to a certain compilation phase), and
there was no reason to use different ones for C and C++.
And for clarity, I have also renamed some exported flags to clearly show
that they are consumed by LIBJSIG and ADLC. I have also renamed "/STACK"
on the Microsoft linker to "-stack", to match how we write options
I believe none of these should have any real effect, but if anything,
they could probably be considered bug fixes.
I have considered whitespace and ordering differences as irrelevant.
I have manually verified that the generated spec.gmk and
buildjdk-spec.gmk matches this (no changes apart from the one listed
above) for linux/x64/gcc, solaris/sparcv9/solstudio,
windows/x64/microsoft and macosx/x64/clang, for release and fastdebug.
I am also currently running a test job using the COMPARE_BUILD
functionality on our internal build system.
I would appreciate if comments are more in the form of "think of this
for subsequent updates to the flag handling" rather than requests to
change this patch, at least for requests that are just not small fixes.
(I've been juggling this for a while, trying to get it right...)
More information about the build-dev