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
