Am 21.11.2023 um 09:44 schrieb Chuanqi Xu via SG15:
> 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