> 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).
Not sure how relevant this is for C++, but soon we will be sending a proposal to Automake for supporting non-optional dependencies and thus having native support for Algol 68, Fortran and Go modules/packages. > 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?
