On Mon, Feb 3, 2014 at 3:03 PM, Magnus Ihse Bursie <magnus.ihse.bur...@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
