On 2019-02-14 15:44, Baesken, Matthias wrote:
Hello,
please review this small change .
On AIX, it adds detection of xlc16 / clang to the build environment.
The xlc16 package contains 2 compiler frontends :
* The legacy xlc
* The new clang-based xlclang++
For older xlc (12 / 13) we should for now still support the "legacy" xlc .
For xlc16 the usage of xlclang++ is desired , because it promises
better C++11/14 support (important for the coming JEPs dealing with C++11/14
features) .
Additionally to the compiler detection , the debug-flag is changed to -g1
when xlclang++ is used (because of issues with -g) ; thanks to Steven for
providing the info.
Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8218965
http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/
Hi Matthias,
I have several doubts about this patch.
Let me start at the highest level before dwelling on details.
Is this really the right way to handle this? Maybe we should either
treat xlclang as a new, separate toolchain, or we should treat xlclang
as a variant of the clang toolchain.
If xlclang is very similar to clang (same compilation behavior, same
compiler flags), then I believe the latter way is the proper way forward.
If xlclang is -- even though the change of frontend -- mostly similar to
the traditional xlc, then the path chosen by you might be the best way
forward after all.
If xlclang is different enought from both the traditional xlc, and from
clang, we might want to treat it like an entirely new toolchain. We can
of course share code with the existing xlc and clang toolchains. I think
this is the best way if e.g. compiler flags are still shared with xlc,
but source code defines etc is shared with clang. That way we can test
for "xlc or xlclang" when setting up flags, but "clang or xlclang" in
the #ifdefs.
---
If we should go forward with your patch, please note the following:
We try to use "true" and "false" as values for boolean variable, so
"AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true".
The test to determine if we're using xlclang seem to happen in the wrong
location. It also calls the bare "xlclang++" from the path, without any
consideration if the user has specified a toolchain path, etc.
I won't go into more details on the patch until we've determined if this
is the solution we should pursue.
/Magnus
Thanks, Matthias
