RFR: 8321533: Clang build for Windows
Daniel Jeliński
djelinski at openjdk.org
Mon Dec 11 08:48:13 UTC 2023
On Mon, 11 Dec 2023 03:42:21 GMT, Kim Barrett <kbarrett 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.
>
> This is effectively creating a new port. That shouldn't be done lightly.
>
> Who needs this? (Real question, not rhetorical.) We've discussed things like
> this in the past (build for Windows using something other than MSVC), and it
> wasn't clear there was a user community sufficient to warrant the effort to
> develop and (especially) maintain such a port.
>
> Who is going to maintain this?
>
> Most "secondary" ports have an associated JDK project that is responsible for
> them. This provides a place for other developers to find the maintainers.
>
> Because there was only the one configuration, there have been places that
> conflate Windows (the OS) and MSVC (the compiler), both in the build system
> and in the source code. And for source code that means both HotSpot and
> native code elsewhere in the JDK. Julian has been cleaning up some of that,
> but I've no idea how much might be left. And things will quickly bit rot if
> there aren't active maintainers.
Thanks @kimbarrett for your input.
I'm not aware of anyone who needs this. I am using clang only for the warnings it reports. It found a number of previously undetected problems.
If new compilers are added on a strictly as-needed basis, this one has no place in the JDK; the Structured Exception Handling implementation in clang is sub-standard, and a hack is required to make it work. The resulting artifacts pass the tests I'm interested in, but I have no intention of running the entire test suite.
I'm only providing this patch to make it easier for others to experiment with clang-cl. If that's not a good enough reason to get this patch merged, I can keep maintaining it in my fork.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1849568982
More information about the build-dev
mailing list