It is a major concern that incremental build of modules may build too many files if the interface units or the included files get changed. To solve/mitigate the issue, I presented two solutions. See https://isocpp.org/files/papers/P3057R0.html for details.The demo tools in the compiler (clang) side are presented. So the build tools are able to do some simple experiments.
If I understand you correctly, you speak about primary module interfaces that
* /use/ headers from the global module fragment
* /export/ using declarations to make names from said headers
visible to importers of the module and also create a dependency to
/parts/ of the contents of those headers as prescribed in
[module.global.frag]/3, taking into account the discarding of
entities that are determined as "unused" according to
[module.global.frag]/4
* /emit/ some of the surviving (the step before) declarations
into the BMI, and the other survivors into the object file. The
target artifact is determined individually by the properties of
each declaration and possibly the way how an modules
implementation works.
In general, each module interface has dependencies
* on all headers that it directly or transitively #includes into
the GMF
* on all headers that it directly or transitively #includes into
the purview
* on all modules from inside or outside the module the interface
pertains to
Those are the dependencies if you look at them on a file / TU
basis. On a finer granularity level, you can look at /actual/
dependencies based on an analysis like the one in
[module.global.frag] as described before, applied to /all/ of the
file / TU dependencies above. Some of the dependencies in the set
above might to turn out to be no real dependencies if you just
look close enough.
What you propose is to go even farther: create a dependency on /all/ explicit or implicit importers of a given module interface, right? I just want to make sure that we are all on the same page.
You envision a mechanism to inform build systems about the /actual/ dependencies of a modules, based on the /uses/ in importers and the entities they reference in the module interface. Correct?
Thanks
Dani