On 2022-03-11 14:34, Julian Waters 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
In theory OS and compiler toolchain are separate things. In practice, in
the JDK, they are not. There is basically a 1-to-1 mapping between
toolchain and OS:
Windows <-> Visual Studio
macOS <-> XCode/clang
linux <-> gcc
(The one possible exception is that clang on linux is probably feasible.)
After years and years on this, all kinds of assumptions has been
hard-coded, even if people try to do the right thing. But sometimes it
is not clear if you are checking for toolchain or os; perhaps when
linking with a specific library, or setting some define.
Any attempt to change this is, as I said, a *huge* undertaking. *And*
there will be tons of negative consequences for the code base as a
whole, when trying to differentiate between toolchain and OS. So this
will need to be seriously considered.
/Magnus
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
