On Tue, Feb 18, 2025 at 17:14:47 -0500, Paul Smith wrote: > On Tue, 2025-02-18 at 16:32 -0500, Zack Weinberg wrote: > > 2) Besides an "is this feature available" probe, I don't know if any > > support for C++ 2020 modules is even *necessary*, because I don't > > know how they work. If any other changes are necessary, they would > > probably need to happen in Automake and Libtool, not in Autoconf. > > Definitely build systems need to be made module-aware, at some level, > for them to work correctly. > > It might be helpful to read about what CMake did to enable C++ modules: > > https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html > > You'll note they didn't implement it for makefiles :-/ :-)
CMake's Makefile implementation can support it; it supports Fortran modules after all. However, `ninja` support is far easier as it (in CMake's implementation) has a single graph for the entire build. The Makefiles generator is a 3-level recursive make in order to implement things like CMake's per-directory entry points. Implementing C++ modules and fixing the *ninja* build graph found a number of assumptions that this structure ends up relying on to provide CMake's semantics to projects. A rewrite of the Makefiles generator to not require this is something we'd like to do, but there's no real way to put it on the timeline at the moment. Basically it would look like the Ninja generator output where there's a single build graph instead of the static recursion level. > There was some very experimental work done alongside GNU Make a number > of years ago, but back then it wasn't clear how we would move forward > with "module descriptions". There were two ideas: one of them a > "scanner" which was sort of like the old makedepend or gcc -MM or > whatever that generated a description of module dependencies, and the > other an LSP-like client-server solution. > > My position so far, from a GNU Make standpoint, is that it's not been > feasible to know how best to proceed, yet. Maybe that is starting to > change and the compilers are coalescing around a solution that GNU Make > could work with. I don't think the client/server setup makes sense for build systems (it can be useful for `g++ *.cpp` interactive usage though). The "collator" command is "just" a regular command as far as `make` is concerned and is scheduled along with it appropriately. The builds are also far easier to debug with a collator because there's not some extra process running around keeping who knows what state as you iterate on a set of commands. --Ben
