Support for different compilers

Magnus Ihse Bursie magnus.ihse.bursie at
Fri Jan 31 13:42:35 UTC 2014

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 

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?


More information about the build-dev mailing list