As Dalibor wrote, I would not expect too many performance surprises. 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.
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 <tanksherma...@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.bur...@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 > > > > > > >
