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.bur...@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
