Support for different compilers

[Martin Buchholz]

In practice, every compiler defines preprocessor symbols that allow
conditional compilation based on compiler type.  So there's not much value
in having configure define yet another "compiler family" variable, or at
least not useful within the C/C++ code itself.

I also think that the "toolchain environment" is much more nuanced.  Each
family comes with a number of variations and version history.  And
low-level libraries may be provided independently of compiler proper.


On Fri, Jan 31, 2014 at 9:27 AM, Henry Jen <henry.jen at oracle.com> wrote:

> On 01/31/2014 08:09 AM, Martin Buchholz wrote:
>
>> I think it's generally wrong to use a "compiler type" just like it's
>> generally wrong to use a "OS type".  Most code should be portable, and
>> most
>> of the rest should use autoconf features "HAVE_FOO"
>>
>> Getting openjdk to build with random compilers (e.g. icc or clang) without
>> adding too much new code is a very good quality improvement effort.
>>
>>
> I think this proposal is mainly targeting the build process, particularly
> on complier flags, therefore we will need to know what compiler is in use
> to set those flags accordingly.
>
> On random compiler, we probably can setting with a minimum set of flags
> and expect it to build the product.
>
> The proposal looks reasonable to me. I assume default would be a ordered
> list of preference on our side instead of a single choice?
>
> compiler-family or compiler-type works for me. :)
>
> Cheers,
> Henry
>
>
>
>> On Fri, Jan 31, 2014 at 5:42 AM, Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com> wrote:
>>
>>  I'm about to start addressing the issue of supporting different compilers
>>> on the same platform.
>>>
>>> The major driver for this project is the compiler upgrade that is about
>>> to
>>> happen in JDK 9. On MacOS X, we will be switching from gcc to clang as
>>> default compiler. However, a complete switch at a single time will not be
>>> easy to orchestrate. Instead, we will be supporting both gcc and clang in
>>> parallel. To do this properly, we will have to make sure that the build
>>> system can understand the difference between "compiler" and "platform".
>>>
>>> Up until now, we've had only one supported compiler per platform, and
>>> (more or less) a different compiler for every platform. In such
>>> circumstances, code tends to be a bit murky -- should we test for gcc, or
>>> for linux, or possibly both? Apart from the actual instances of testing
>>> for
>>> compiler/platform, there have been no good framework to support this
>>> notion
>>> of compiler vs platform.
>>>
>>> My plan is to achieve the following end result for the user:
>>>
>>> * A new configure flag, presumably --with-compiler-type which can be set
>>> to any of the supported compiler types: gcc, clang, mscl, oracle-studio.
>>> For every platform, there is a default that will be used if the flag is
>>> omitted. Setting the flag to a non-supported combination will result in a
>>> warning, if it is possible but untested (like gcc on solaris), or a
>>> failure
>>> if it is impossible (e.g. mscl on linux is not available).
>>>
>>> * If the flag is set to a non-default but possible value, we'll try to
>>> locate a compiler of the given type.
>>>
>>> * Alternatively, one can explicitely request a specific compiler binary
>>> to
>>> be used by setting CC= and CXX=. Setting just one of them will result in
>>> a
>>> warning, since a mismatch is likely in that case. In this case, we'll
>>> test
>>> the given compiler to try to determine it's type. Failure to properly
>>> determine the type will result in an error, since then we don't know what
>>> we're dealing with.
>>>
>>> * For users with special needs, maybe running some kind of special build
>>> or a wrapper around gcc, it is possible to combine the two. In that case,
>>> we'll use the binaries pointed to by CC and CXX, and will assume that
>>> they
>>> are of the type given by the --with-compiler-type. We will check if we
>>> agree with the classification, but if not, we will still take the user's
>>> given type by face value and just inform the user of this mismatch. In
>>> this
>>> mode, compile failures can occur even if configure succeeded.
>>>
>>> I'd appreciate any input or feedback on this solution.
>>>
>>> For instance, is "compiler type" a good name, or would "compiler brand"
>>> be
>>> better?
>>>
>>> /Magnus
>>>
>>>