Support for different compilers

[Martin Buchholz]

I'll concede that when determining default compiler flags, those are highly
dependent on something like a "compiler family" and cannot be done in the
C/C++ sources themselves.  But even then, for many of the compiler flags
there should be feature based autoconf tests instead of relying on guessing
based on compiler family, e.g. does -Wl,-rpath work?


On Mon, Feb 3, 2014 at 12:12 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> I agree. The issue with different compilers are basically in the flags and
> how the toolchain works. The source code should not be modified if it can
> be avoided. On the other hands, compiler flags typically needs to be
> completely written from scratch to support a new compiler.
>
> /Magnus
>
> > On 3 feb 2014, at 07:43, David Holmes <david.holmes at oracle.com> wrote:
> >
> > 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
> >>>>>
> >>>>>
>