Support for different compilers

[Volker Simonis]

On Mon, Feb 3, 2014 at 3:03 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
>
> On 2014-02-03 10:36, Volker Simonis wrote:
>>
>> Hi Magnus,
>>
>> I think that supporting multiple compilers per platform will be really
>> helpful to make the code base more robust and portable.
>
>
> I have started working on this now, and the result is really pretty. The
> configure code ges much clearer, and now that it is easy as pie to add a new
> compiler, I've started testing with using clang and Oracle Solaris Studio on
> linux as well. I'm not sure anybody would want that (well, clang, yes, of
> course), but if the code can be compiled that way, it's nice if configure
> doesn't stand in the way.
>
>> How do you plan to address the fact that during he build process we
>> are actually already using two different compilers - the "build"
>> compiler which builds various tools used during the build process and
>> the "target" compiler which builds the actual bits of the JDK. There's
>> already bug "8029375: configure needs a way to customize
>> compiler/linker options for the "build" compiler"
>> (https://bugs.openjdk.java.net/browse/JDK-8029375) which objects that
>> there's currently no way to specify special flags for the "build"
>> compiler.
>>
>>
>> If we support different compiler families, we should think about this
>> and if we want to allow different compiler families for the "build"
>> and "target" compilers.
>
>
> Actually, one of the ideas I got when working with this was to get rid of
> the build compiler. That would indeed save us a lot of trouble. And we don't
> *actually* need one; for Christ's sake, we're developing a platform-neutral
> runtime -- go and use it! :-) In fact, the majority of our build tools are
> indeed written in Java. The're are a few one's that's left, in the JDK it's
> genSocketOptionRegistry, genUnixConstants, genUnixConstants,
> add_gnu_debuglink and fix_empty_sec_hdr_flags and fixpath. All of them are
> simple, one-file-only tools.
>
> While not trivial, I think we can get rid of them. The gen* tools seems
> broken from a cross-compile perspective; they convert build-platform
> constants into Java code. Fixpath is only needed on Windows, we're we can't
> cross-compile, and so can use the default compiler instead.

As always, you forget the Windows/IA64 which can be only cross-compiled:)

But OK, I'm pretty sure we won't support Java 9 on Windows/IA64 and I
hope Java 8 neither.

Theoretically you could also cross-compile Windows/AMD64 on a 32-bit
Windows box, but that's probably a more exotic case nowadays where
everybody has a 64-bit Windows machine.

> The remaining
> two are fixes for old brokenness in Solaris tools. With some luck, they are
> not needed anymore if we can require a new enough OS version/toolchain.
>
> Then there's a remaining bad guy, the adlc compiler in Hotspot.
> Unfortunately, this is a large tool, and converting it to Java would be a
> more massive undertaking. :-(
>

Yes, I agree. I don't see this happening any time soon also that would be nice.

> Going back to your question: I don't think it's much point in considering
> the build toolchain on equal basis to the target toolchain. More or less any
> old compiler hanging around would do. :) Obviously, from the bug you linked
> to, it might need some more love than that. Adding a user-defined separare
> flag is of course possible, and even easier to do after the changes I'm
> working on. And we probably need to add some flags by default, e.g. on AIX.
> But I do not think it's a good point bringing in the whole compiler family
> business here.
>
>
>> PS: I'd prefer the name "compiler-family", as suggested by Henry
>
>
> I started using "toolchain type" in my work. I think it better captures the
> idea that it's not only the compiler we're talking about here. "Toolchain
> family" might be good as well, but is longer to type (and the names are
> looking long already!) and it misses the alliteration touch. ;-)
>
> I'll send out a webrev with some preliminiary stuff soon to get some input.
> Changing "toolchain type" to "compiler family" is just a search/replace
> away, if there's enough pressure. :-)
>
> /Magnus