On Sat, Jun 12, 2021 at 6:29 PM David Blaikie <dblaikie_at_[hidden]> wrote:

> On Sat, Jun 12, 2021 at 2:18 PM Daniel Ruoso <daniel_at_[hidden]> 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.

Daniel

>