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
