Support for different compilers

[Eric McCorkle]

Clang support on all platforms would be nice.  Clang comes with full
cross-compilation ability, so it could be possible to set up a machine
(or machines) that produce builds for all platforms.

At the very least, the BSD ports should support clang, as FreeBSD now
uses clang by default.

On 01/31/14 08:42, Magnus Ihse Bursie 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