Support for different compilers

[David Holmes]

Hi Martin,

On 1/02/2014 4:30 AM, Martin Buchholz wrote:
> In practice, every compiler defines preprocessor symbols that allow
> conditional compilation based on compiler type.  So there's not much value
> in having configure define yet another "compiler family" variable, or at
> least not useful within the C/C++ code itself.

On the contrary! We want to isolate compiler idiosyncracies to the 
makefiles/build-system NOT the sources. Compiler based ifdefs should be 
an absolute last resort in my opinion.

David
-----

>
> I also think that the "toolchain environment" is much more nuanced.  Each
> family comes with a number of variations and version history.  And
> low-level libraries may be provided independently of compiler proper.
>
>
> On Fri, Jan 31, 2014 at 9:27 AM, Henry Jen <henry.jen at oracle.com> wrote:
>
>> 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.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
>>>>
>>>>