RFR: JDK-8034788 Rewrite toolchain.m4 to support multiple toolchains per platform

Henry Jen henry.jen at oracle.com
Fri Feb 14 19:50:15 UTC 2014

On 02/13/2014 12:41 AM, Magnus Ihse Bursie wrote:
> Henry,
>> - Do we want to allow convention name cc and CC and detect what it
>> is or simply ask for explicit choice as it is imeplemted now?
>> Although I don't think it's likely for a system to install, say
>> gcc, as cc instead of create a symbolic link alias for gcc, I
>> cannot be sure.
> I didn't say so in my previous mail, but one follow-up functionality
> I'm planning to implement is to set compiler using CC or CXX. In this
> case, we'll try to detect toolchain type automatically. But unless we
> specify CC explicitly like that, I believe the best way is to default
> to a toolchain and try to detect it using conventional names, e.g.
> bcc.

I think this is important to recent parfait effort as well or any
wrapping tools for compiler.

>> - I understand clang is not a goal for this patch. From experience,
>> it's almost work like gcc. Does it make sense to have gcc flags as
>> a fallback? This bring up the question before, should we have a
>> fallback default to unknown toolchain? Even if we check for
>> supported toolchain, all such setting should probably still be
>> defensive with gcc as default. Otherwise, I can configure with
>> clang but quite a few setting would be missing.
> I do not like the idea of a fallback like that. If we cannot detect
> the compiler, then things are likely to go wrong. And one core value
> in the configure thinking is that if it should fail, it should fail
> early, in the configure step, not in make.
> The one reason I can see for not enforcing us to detect compiler
> correctly is if you're adding support for a new compiler, like clang,
> and have not bothered to write the new detection code yet. In that
> case, you'll just have to comment out the check.

I agree we should fail early, and what I meant to say is that we need to
have a catch-all on those toolchain specific setting code to either have
an error or minimum default(perhaps a nop, which is probably what is
implemented already).

The thinking is to make sure we won't miss any spot that need to be
modified when adding a new toolchain support.


More information about the build-dev mailing list