On Sat, Jun 12, 2021 at 6:29 PM David Blaikie <dblaikie@gmail.com> wrote:
On Sat, Jun 12, 2021 at 2:18 PM Daniel Ruoso <daniel@ruoso.com> wrote:
Yes, but you would be scanning files that you are expecting to build anyway.
A bit, this might be getting a bit jumbled up with a few different directions that exist/are being implemented. 
Google's Bazel-like monorepo (Clang Header Modules, rather than C++20 modules) starts with an explicit dependency graph from BUILD files, but then also does a prescan
I think this is a good example of how the Modules specification suffered from not being built on top of a package management spec. Which is the distinction of what a bazel-like monorepo can do and why a "source to binary" build will have a harder time sorting that out.
In "source to binary" we don't have the context of how that module is meant to be parsed, we only have the context for this particular translation unit.
Other than in something like a pkg-config file, yeah?
Right, except the pkg-config instructions are already for the main translation unit, so we'd need something new to say "here's what you need to parse the module files, but you don't need it to parse your own code". 

What I'm advocating for is an additional format that provides a middle ground between the BMI and having to do a complete parse
*nod* I can see how that's a nice to have - I don't think anyone's signed up/planning to build something like that as yet and I don't think it's necessary to the success of the feature
I do acknowledge that R7 is a lot less critical than the other requirements set here.