Support for different compilers

[Magnus Ihse Bursie]

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. 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. :-(

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