Supporting alternative toolchains on Windows

[Magnus Ihse Bursie]

On 2022-03-11 18:18, Thomas Stüfe wrote:
> As Dalibor wrote, I would not expect too many performance surprises.

Actually, I would seriously assume that any other compiler than VS on 
Windows will give much worse results. The VS compiler is 
battle-hardened. Gcc and clang is only used by a very small enthusiastic 
hobbyist minority. There is no reason to believe it will be even close 
to optimized. Most likely there will be strange bugs with anything that 
requires OS interaction (like dll loading and whatsnot), even if the 
basic code generation part of the compiler should be identical for all 
OSes running on the same CPU.

>
> That said, a more pragmatic approach may be to create a shim layer for 
> visual studio compiler and linker, e.g. a fake "cl.exe" and "link.exe" 
> that translate VC++ options and paths to whatever toolchain you like. 
> That way you don't have to touch the OpenJDK make at all. I know it 
> works in principle since I have such a thing in the past, albeit for a 
> different product and a different target toolchain.

But there is oh so much to "convert" in that case. Just try grepping for 
"pragma" in hotspot, for a start. :)

I seriously do not believe this approach would be any ounce simpler, at 
least not for the JDK.

I did actually start to try to get a "hybrid" mode working, where the 
Visual Studio CL compiler would be run using wine on linux. (This was 
previously not allowed by MS licence, but they changed it some years 
ago.) That'd had allowed for linux users to cross-compile to Windows, 
and make a quick check that you did not break the build. But even this 
small step -- keeping the Windows compiler, but running in a linux 
environment -- turned out to be so full of tricky details that I gave up 
on it.

/Magnus

>
> I would not be surprised if such a thing exists already. It seems such 
> an obvious idea.
>
> Cheers, Thomas
>
> On Fri, Mar 11, 2022 at 2:35 PM Julian Waters 
> <tanksherman27 at gmail.com> wrote:
>
>     Darn, seems like it'll be much harder than I expected. Since multiple
>     toolchains are supported for macOS and Linux, I assumed a slight patch
>     would help get it to work on Windows. Looking through the stuff in
>     make
>     though, it appears a lot of the build system implicitly expects the
>     compiler for Windows to always be Visual C++, which doesn't really
>     help
>     that much (Though the fact that we can exclude many versions of
>     gcc, such
>     as Cygwin's and old MinGW binaries helps a lot). The build process
>     for the
>     newer Windows ports of gcc are surprisingly similar to Visual C++
>     though
>     (Eg rc can be swapped out for windres) so this might hopefully be
>     something
>     I can try exploring in the future (Gonna look a bit harder at make and
>     write what I can find back to this mailing list in the meantime).
>     It'd be
>     interesting if benchmarks of the JVM compiled with different
>     compilers on
>     Windows can be compared side by side on the off chance this becomes a
>     reality though
>
>     best regards,
>     Julian
>
>     On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
>     magnus.ihse.bursie at oracle.com> wrote:
>
>     > On 2022-03-11 12:55, Julian Waters wrote:
>     >
>     > > Hi all,
>     > >
>     > > How feasible would it be/much effort would it require to support
>     > compiling
>     > > with alternate toolchains on Windows besides Visual C++ (like
>     the Windows
>     > > ports of clang and gcc) if we restrict the allowed toolchains
>     to only
>     > those
>     > > that link against the ucrt? (Toolchains linking against the
>     dated msvcrt
>     > > would present too many issues to work with)
>     >
>     > That'd be a huge undertaking. And any such patch would only be
>     accepted
>     > into the code base if the organization behinded appeared
>     trustworthy in
>     > their long-term commitment to keeping it working.
>     >
>     > /Magnus
>     >
>     >
>     >
>