RFR : 8218965: aix: support xlclang++ in the compiler detection

[Magnus Ihse Bursie]

On 2019-02-15 14:30, Baesken, Matthias wrote:
>> Are they both pointing to the same binary, and the mode of operation
>> (legacy xlc vs xlclang) is determined by the name of the executable?
>>
> Hello, in the installation I use   I have separate  binaries .
>
>
>> Is xlclang++ always available for version 16+ of xlc?
>>
> I think so,  as least I am not  aware of an installation mode with separate  binaries .
> However I am not an XLC  installation guru 😊 .
>
>> If so, maybe we should just make sure we call the compiler with the
>> correct name if version 16+ is detected?
>>
> I thought  that we currently  first set  the  toolchain  name and then  set a fix  name for the binary  and check the version .
> But I might be wrong.  Maybe  we need  to adjust this .
> Or just at some future  point in time  declare  xlc16   as minimum   requirement  (this makes things  easier , we can then use  the new binary names   ).

Yeah, we can adjust the process if needed. And to solve this *properly*, 
we should. I still think this looks like the wrong way to do it. But...

If we're talking about a short migration story, where soon XLC 16 will 
be required, and we can just replace

TOOLCHAIN_CC_BINARY_xlc="xlc_r"

with

TOOLCHAIN_CC_BINARY_xlc="xlclang"

then I can accept it anyway, so we don't need to complicate things.

I also don't like how xlclang is just run from the path, but OTOH it's 
only you guys who are going to run that in practice, and it's just going 
to be temporary, so, whatever.

The name AIX_USE_CLANG is not really correct, though. This is not about 
AIX. It should be XLC_USE_CLANG (or maybe better XLC_USES_CLANG, even 
perhaps XLC_IS_CLANG?!). And, as I said, it should use true/false, not 0/1.

If you fix this, and we agree that this is a temporary measure, I'm OK 
with the patch.

/Magnus


>
> Best regards, Matthias
>
>
>> -----Original Message-----
>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>> Sent: Freitag, 15. Februar 2019 13:32
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> dev at openjdk.java.net' <build-dev at openjdk.java.net>
>> Cc: Doerr, Martin <martin.doerr at sap.com>
>> Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection
>>
>> On 2019-02-15 12:53, Baesken, Matthias wrote:
>>> Hi Magnus,
>>>
>>> we are currently  able to build (+ test 😊 )    jdk/jdk   on AIX   with the
>> xlclang++  based build .
>>> Only needed  are  this change ,
>>> plus   a one-liner  in harfhuzz  is needed   (we try to get this upstream  into
>> harbuzz directly,  in case the next harfhuzz update to jdk/jdk  is in the mid/far
>> future ,  I would add this one liner to my patch).
>>> So I  hope  that  there will be not so many follow ups   (but you never know
>> ).
>>
>> Ok, that's good to hear.
>>>> If so, could the choice between -g ang -g1 be handled with the normal
>>>> TOOLCHAIN_CHECK_COMPILER_VERSION?
>>>>
>>> I'll look into this .   Unfortunately  the  version output is the  same for  both
>> frontends :
>>> New one:
>>>
>>> bash-4.4$ xlclang++ -qversion
>>> IBM XL C/C++ for AIX, V16.1.0  (some-strange-hex-string)
>>> Version: 16.01.0000.0001
>>>
>>> Legacy xlc:
>>>
>>> bash-4.4$ xlC_r -qversion
>>> IBM XL C/C++ for AIX, V16.1.0  (some-strange-hex-string)
>>> Version: 16.01.0000.0001
>>>
>>>
>>> (and  some-strange-hex-string  is  the same for both)
>> Hm.
>>
>> Are they both pointing to the same binary, and the mode of operation
>> (legacy xlc vs xlclang) is determined by the name of the executable?
>>
>> Is xlclang++ always available for version 16+ of xlc?
>>
>> If so, maybe we should just make sure we call the compiler with the
>> correct name if version 16+ is detected?
>>
>> Or is there a way to force xlclang mode using a flag?
>>
>> /Magnus
>>