On Mon, 11 Dec 2023 03:42:21 GMT, Kim Barrett <kbarr...@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
