Thanks Gaby and all others,
I agree that this is formally nothing to discuss within the C++
standard committee.
We see a bit the consequence of inventing on the fly instead of
standardizing existing practice.
This is well within the remit of SG15 and the planned TR, though. While not a normative standard, SG15 has been planning to supply guidance that compilers, build systems, and package management systems can follow to improve inter-op so we can make modules successful. We can talk about things like file systems, search paths, compiler flags, and so on that we have no way to, or strong agreement to, talk about in the standard itself. An important one is a format for the compiler, or compiler supplied tool, to communicate module dependency information. We know scanning can be done with modern techniques much faster than in the past. Compare tools like ripgrep with the standard grep, for example. However, we don't want to go back to the almost accurate dependency information produced by, e.g., xorg's makedep. Only the compiler knows its own rules well enough to follow what it would do.
But if we are interested in the success of modules, we should
care.
Simplicity is a key for the success of new ideas.
So, while I agree that we need build systems in projects of
significant size, the question is whether we still keep things as
simple as possible. And the question is which burden we put not
the build tools.
IMO a compiler should parse a C++ file while a build system
should not have to do that.
Compiler implementation. Possibly a separate tool, or something found by the compiler driver. But it can't be done as a side-effect of compilation as we do with header deps today. The directed graph has to be built before you can schedule all the compilation, as in the worst case you could get an out of date module interface used without being rebuilt. And that's worse than it not being available, because it's wrong but appears to succeed.