They require manual specification of include paths, but not of what .cpp files depend on what .h files. However, at least on Unix, this is not typically done b

They require manual specification of include paths, but not of what .cpp files depend on what .h files. However, at least on Unix, this is not typically done by having the build tool parse C++ files. Rather, while compiling a given .cpp file, the compiler is instructed (using -MD or other variants starting with -M) to output a .d file listing all the header files it encounters as it goes, which are then treated as dependencies. The output format is a subset of the Makefile language with just file dependencies (like “a.cpp : b.h”) rather than compilation rules; thus, anything that uses make as a backend (including autotools, cmake in that mode, etc.) can just have the Makefile ‘include’ all .d files, and make will do the right thing. (Alternative backend build tools, such as ninja, have to parse the .d files themselves, typically supporting only that subset rather than reimplementing all of make!) You don’t have them for the first compile, but that’s okay: the dependencies are only used to skip recompiling files if none of their dependencies changed. This design replaced an earlier one where the user had to manually run ‘make depend’, which would pre-scan for dependencies using a separate tool, makedepend(1). First ‘gcc -M’ was added as a straight replacement of makedepend, then -MD and variants were added to write dependency files while compiling each object file rather than requiring a separate invocation (which is slower). But it sounds like modules will complicate things, since it could be mandatory to gather dependency info upfront in order to compile modules before files that depend on them...