Supporting alternative toolchains on Windows

[Dalibor Topic]

On 11.03.2022 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

I wouldn't necessarily expect large differences between builds compiled 
with different C/C++ compilers on industry benchmarks like SpecJBB, 
since the JVM will spend most of its time executing code it JIT-compiled 
itself.

I think more interesting from a developer/CI perspective would be 
potential differences in compilation speed, but I would naively assume 
those to be dominated by the linker, rather than the compiler itself.

cheers,
dalibor topic

> 
> 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
>>
>>
>>

-- 
<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