On 11.03.2022 18:18, Thomas Stüfe wrote:
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.

For clang there is https://clang.llvm.org/docs/UsersManual.html#clang-cl but I have not tried it myself. But then again the linker step might be problematic.

cheers,
dalibor topic


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





--
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRB 246209
Geschäftsführer: Ralf Herrmann

Reply via email to