Many people use CMake and many people want to use C++20 modules. CMake’s support is WIP (but quite visible, they do point people to that issue for updates). The most recent update describes how using C++ modules with CMake requires a patched clang, which essentially carries ⚙ D137059 [Driver] [C++20] [Modules] Support -fmodule-output= (2/2) & ⚙ D139168 [C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4).
It’s getting very tight to land these before the branch, and perhaps it’s already too late. On the other hand, these series have been pretty stable for ~2 months, and are being used in the CMake how-to for modules.
I just wanted to raise that question for wider visibility because C++20 modules (resp. lack thereof) is something that continues to attract a lot of attention, and being able to use CMake + unpatched Clang would make things much more accessible (also for bug reports), even if it remains marked experimental.
CC people involved in those series @ChuanqiXu @ben.boeckel @dblaikie @jansvoboda11 @Bigcheese @tahonermann
CC Clang stewards & LLVM release managers @AaronBallman @erichkeane @tstellar @tobiashieta
Relevant discussions (not a complete list):
9 Likes
Thanks for pushing this forward! I think it is pretty important for the wider users to use C++20 Modules with official CMake support. The current status of C++20 Modules in clang is not good enough clearly. (Personally, I would like to call the status quo as alpha than experimental since alpha looks more precise). But I feel it would be pretty hard to make it good enough without the feedback from wider users.
For these patches,
(1) Thanks to @dblaikie, the -fmodule-output patches are accepted and landed. (@dblaikie still has some comments about to merge the implementation with splitting dwarf.)
(2) For the clang-scan-deps patches, I am wondering if we can land them first if there is no big or blocking issues. And if there is any big or blocking issue from the perspective of @jansvoboda11 , I am wondering if we can get a consensus that we can back port these patches to 16.x before the release of 16.0.
How do you think about the suggestion? I feel this is important since a lot of users don’t compile the compiler from source and they have to wait until September if we missed the opportunity.
1 Like
I’m not particularly familiar with modules, as @BigCheese and @ChuanqiXu are the code owners.
That said, I’d immediately want to ask: What is the ‘risk’ to adding these? I see the 1st has already been landed, so the question ends up being for the 2nd only. Additionally, what is the ‘reviewed’ status of these, particularly to the code owners?
What is the ‘risk’ to adding these?
Personally, I feel there is not a particular ‘risk’ for existing users. The second series is about clang-scan-deps. So it wouldn’t affect the clang users. And for the clang-scan-deps it self, I add a new mode for clang-scan-deps. So it shouldn’t affect the existing clang-scan-deps users.
Additionally, what is the ‘reviewed’ status of these, particularly to the code owners?
Currently, @jansvoboda11 is reviewing the clang-scan-deps patches. He gave some thoughts about the design it self. And I am waiting for his feedback after I addressed his comments. @jansvoboda11 is the main active maintainer for clang-scan-deps AFAIK.
I feel we are hard to land these patches before branching since I am taking a vacation from tomorrow to February. So I am wondering if we can backport these patches to 16.x before the release.
In that case, it is obviously up to you as modules owner, but if you’re happy that there is low risk to existing code and that it is sufficiently reviewed, it would make sense to add them.
2 Likes
Hi all,
from me as a consumer/tester perspective, it would be of course great to have merged modules changes for CMake in 16 release.
I did create a local checkout of current pending changes via @ben.boeckel’s repo as described here and have a CI pipeline running on it but I didn’t have much success when testing it against my projects. That could be due to missing fixes from LLVM master branch (it’s 3K commits behind). So if these changes would be merged it would be easier to test and give feedback.
2 Likes
Just stumbled over this blog post by the CMake folks today, which appeared a couple days after this thread opened, and obviously magnifies the “quite visible” part.
I also saw that @ChuanqiXu is back, and planning to land the missing patches for LLVM 16, which would be amazing! 
2 Likes