Support for different compilers

[Martin Buchholz]

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.


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
>