RFR: 8321533: Clang build for Windows

[Magnus Ihse Bursie]

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

I tend to agree with both Camp Kim and Camp David/Julian here. In many ways, the code gets healthier the more variation we have, i terms of support for operating systems, architectures, compilers and C libraries. Both the actual code base gets more exposure which can force out bugs that were lurking in the dark, and the build system gets a requirement for clear separations and structure. So in general, I like to see more compilers and platforms in the JDK!

But, then there is Kim's argument about maintenance cost. And it is not to be taken lightly. If the port can be "sneaked in" without much effort or impact on other code, then it essentially free, and even if it is not strictly needed, or we do not have an active maintainer, I see no problem with using it. Great examples of this would be the zero ports on odd CPUs, like MIPS.  The more the port interferes with existing code, the higher this barrier becomes.

But there is also a second cost associated with new ports (I'm counting the new compiler as a port, in this context), and that is the arbitrary differences that do not bring forth any solved bugs, or good abstractions. All these "#ifdef on_this_platform do_it_that_way". If you need many such changes, this also raises the barrier for inclusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1850201488