On Fri, 2025-02-21 at 12:26 +0100, Ben Boeckel wrote: > 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. I fully agree that the makefiles generated by cmake are... sub-optimal. Automake-generated makefiles use a single build graph (or can do so) and they are POSIX-standard makefiles. So it should be possible to create POSIX-standard makefiles which still have these features. This is actually simpler for CMake than for "hand-rolled" makefile environments since the generated makefiles can avoid tricky parts like conditionalized content, implicit rules, etc. I think it should be possible to preserve the per-directory entry points, now that POSIX make supports "include". Another alternative is to leave the UNIX Makefiles generator as-is, and create a new generator for GNU Make makefiles, which take full advantage of GNU Make features. I don't have any idea what the appetite is in CMake-land for doing this work.
