Hi! I also looked into this problem some time earlier this year. You can find my result and the discussion with the community at a thread named "RFC: A redesign of `-Mmodules` output" in the February and March mailing list. I had an analysis of why things are what they are right now (related standard proposals, GCC's motivation and limitation of current behavior), which haven't changed, so at least that bit would be useful.
The CMake documentation Ben sent provides a robust and complete design from a high point of view. It sums up pretty much everything you need to care about on C++20 modules as a build system developer. Also, I have 2 articles that might be of your interest: https://vspefs-scons-cxxmodule-1.pages.dev and https://vspefs-scons-cxxmodule-2.pages.dev. Yes, it has "SCons" in their titles, but only the last bit in the 2nd article is about SCons. I tried to provide the fullest picture of the reality, useful facilities, and challenges of building C++20 modules. Also, I proposed 3 major ways of implementing it, which kind of overlaps with the CMake documentation and Ben's reply in this thread, but is still worth a read if you ask me. And if you can, do read the thread and the Reddit post it mentioned. Much of the discussion is beneficial for looking at C++20 from a fuller picture. > For the translation of programs with C++ modules, the use of special > build systems is necessary. Yes. That's why we have to consider the users of the `-M` output. That is either a direct Makefile user or a build system. For a direct Makefile user, they might want to use implicit rules for convenience, whose usage is disabled by grouped targets. And for a build system, many of the heavy lifting can be moved to the build system at configuration or generation stage. Less script in Makefile, faster the build process. And Ben is right, C++20 modules is not for Make. So I think our main target here is Autotools or any other build system that depends on Makefile recursion. If we also support standalone Makefile rule generation that could be the cherry on top, but first and foremost I think we need to make modules work with Autotools (which would definitely involve modifying Autoconf or Automake source as well). Also, there are many problems that are "distribution" problems instead of "building" problems. > 2. (gcc) Add the dependencies on imported modules in form of a variable. > (CXX_MOD_<module name>_CMI) This is the tricky part. We can't assume there's only 1 CMI for every module because CMIs are terribly incompatible. There are reasons to have more than 1 CMI for a module in a single build. Other challenges are mentioned in Ben's reply, but they are more of a "higher point of view" stuff, and this is a lower, DAG-level problem. > You can find a longer description here: > https://github.com/joergboe/MakeItSimple/discussions/8 (Chapter: The > Build Process with C++ Modules) What's your idea of libcody and GCC's built-in module mapper by the way?
