Repository navigation
Adding ClangCL to the CI #4001
Description
Plan
Since Node.js can now be compiled with ClangCL on Windows, I'll start adapting the CI to start using that. Here is the plan in short and we'll work out the details as we go forward:
- Start compiling with ClangCL - Initially, we can add only x64, and later include arm64 too. The idea is to compile for some time to gain confidence. This phase should not be too long unless we encounter some issues.
- Start testing the ClangCL-produced binaries - This is a second phase, that will be prepared during the first one (eg. detecting flaky tests, fixing them or marking them flaky, etc).
- Start releasing ClangCL-produced binaries - This will happen after we gain enough confidence from testing. At this point, we can start thinking about dropping MSVC support in the long run or at least making it a lower-tier compiler on Windows.
Preparation
This part is done, as a part of it I did the following:
- Configured compilation machines to be able to compile with ClangCL. I've also made ansible changes so that the machines we create in the future will be ready to do it out of the box
- Added new labels for both compiling and testing the ClangCL setup.
- Created temp jobs where I tested all of this before moving to the main Windows fanned job.
Other work
Besides the main plan, there are some things to take care of as well (this list might get new entries later on):
- Enable compilation caching for ClangCL - ccache we are using for MSVC doesn't work here, I'm currently trying out ccache, but it is also not working out of the box because of the build process (V8 is generating some files in the
objdirectory which interferes with PCH).
Activity
StefanStojanovic commentedon Mar 6, 2025
An update on this. Both x64 and arm64 architectures are compiled with ClangCL now, and thanks to
ccacheit is after than MSVC. Since the debug compilation job uses the release configuration, it will start building with CLang once we enable it in the release CI.Next step is enabling the tests. I've already prepared everything, but there is a question of bandwidth as we will run double the set of tests now. I will probably start by enabling 1-2 configurations to begin with. VS2022 configurations need to be enabled last as those machines are already under a bigger load due to the increased number of compilations per run.
Also just want to note that I've already tested both debug compilation and testing in my temporary job and all passed fine so I'm not expecting any big issues with it other than the bandwidth.
targos commentedon Mar 6, 2025
Thanks for the update. Is the goal for Node.js 24 to remove MSVC support? Asking since I still got no answer about the Windows issues on nodejs/node#57114, where Clang builds pass, but MSVC builds fail.
StefanStojanovic commentedon Mar 6, 2025
Yes that is the idea. Next week I can try and resolve the issues with MSVC, in case ClangCL doesn't get ready for v24, but I would like to see v24 release happen with ClangCL. That is also the reason why I still haven't got to that as I focused on Clang CI changes.
By the way, should I start some kind of discussion with TSC (or someone else) regarding the transition to Clang in v24? It is still not ready (will be ready in time I think), but maybe it'll be too late to open that question later?
targos commentedon Mar 6, 2025
I guess it doesn't hurt to ping @nodejs/tsc since the change will be semver-major.
joyeecheung commentedon Mar 6, 2025
In general transitioning to Clang in v24 SGTM. Though I wonder if there are any problems with addons? I recall that @nodejs/node-api did a lot of investigation in the ecosystem during the development of N-API. Is there some kind of list of popular projects using addons that we can look into and double check?
targos commentedon Mar 6, 2025
You mean that addons built with MSVC might not be compatible with Node.js built with Clang?
joyeecheung commentedon Mar 6, 2025
Yes, for example the ones that might be using MSVC options in the configurations for Windows. I think some breakage should be expected, but it would be better to provide something for them to workaround/adapt to Clang in 24 (e.g. do we expose the clang == 1 variable to them to create some conditions?). Theoratically it should be possible to link an MSVC-compiled addon to Clang build still, but I am not sure if the options we use for clang + the options from common.gypi for MSVC etc. can produce ABI compatible builds? If not they might need some kind of indicator to switch to a different toolchain in their script when being built against v24 too and do some adjustment in their config for v24.
legendecas commentedon Mar 6, 2025
Node-apis are just C APIs and it might be a different case from C++ Addon APIs. From https://clang.llvm.org/docs/MSVCCompatibility.html, it reads to me that Clang provides ABI compatibility guarantees.
For
common.gypi, node-api addons can be more easily compiled without gyp configs as not depending on V8 headers. However, projects like https://github.com/cmake-js/cmake-js can be used for both C node-api and C++ API. cmake-js only supports clang on UNIX systems as the document of--prefer-clangsuggests.joyeecheung commentedon Mar 6, 2025
I meant that the N-API effort was initially a migration effort so the team may have an idea about what tricky things the ecosystem is doing with their addon build config that might be relevant :)
8 remaining items
StefanStojanovic commentedon Apr 7, 2025
OK, I'll look into it tomorrow. Thanks for the feedback.
StefanStojanovic commentedon Apr 8, 2025
I've set up the CITGM job to add ClangCL for x64 and arm64. I ran it once. ARM64 failures are the same regardless of the compiler. x64 compilations failed because of free space on one VM, which is critically low (investigating it now). Once all machines have enough free space I'll rerun x64 CITGM jobs to compare them.
StefanStojanovic commentedon Apr 8, 2025
In both x64 and arm64 CITGM runs, I see the same results (failures) with both MSVC and ClangCL. Next, I'll go through this list and see if there are any differences.
joyeecheung commentedon Apr 8, 2025
By the way it's worth noting that CITGM in general isn't always green. So as long as it doesn't produce more failures than the MSVC one it should be good enough.
StefanStojanovic commentedon Apr 9, 2025
Yes, that was my plan too, not necessarily to have it all green, but to make sure ClangCL is not breaking something MSVC is not.
StefanStojanovic commentedon Apr 10, 2025
I also went through the list mentioned above, and again, the same behavior with MSVC and ClangCL. Can I take this (together with the CITGM results) as a green light to proceed with opening a PR in build and change the release CI build job to use ClangCL? In addition, I'd also disable compiling Node.js v24+ with MSVC in test CI, as that is a bottleneck (doubling the number of the longest jobs in the CI).
cc @nodejs/tsc @targos @joyeecheung @legendecas @mhdawson
targos commentedon Apr 10, 2025
Did some of your tests involve running an MSVC-compiled addon with the ClangCL-compiled node.exe ?
If yes, I think we're good to go!
joyeecheung commentedon Apr 10, 2025
@StefanStojanovic Do you still have the links to the CITGM runs?
StefanStojanovic commentedon Apr 10, 2025
I think so, but I'm not sure (I've worked on this on and off for some time). I'll try that tomorrow to double-check. Do you have a specific addon example in mind, or is a simple hello world addon enough?
Here they are: x64 and arm64
joyeecheung commentedon Apr 10, 2025
I took a brief look - not sure if I missed any that was actually working, but it seems the addons have all been failing to build with MSVC on v24.x already?
StefanStojanovic commentedon Apr 11, 2025
Yes. Looking as far as Jenkins allows (20 March at this time), I cannot see any run that didn't have all configurations red.
StefanStojanovic commentedon Apr 11, 2025
I've just finished testing this again. Everything works well for me. I tested a few scenarios with passing and/or returning strings and numbers. Saw no problems with it.
StefanStojanovic commentedon Apr 11, 2025
I was preparing to open the PR, but noticed some issues, as test and release CI labels are connected in a way, but are actually used differently. Currently trying to find the easiest way to fix it. Might need to change some labels in the test CI. Should have it all ready on Monday.
StefanStojanovic commentedon Apr 24, 2025
Closing this, as it is done.