> On 13 Oct 2022, at 10:01, Daniel Ruoso <daniel_at_[hidden]> wrote:
>
> Em qui., 13 de out. de 2022 às 10:41, Iain Sandoe via SG15
> <sg15_at_[hidden]> escreveu:
>> I expect that this has been discussed before, and I’ve missed it somehow .. but several times during my implementation work on clang, it seemed to me that this problem would go away if importable header units were required to start with a keyword.
> ...
>> Given an expectation that the user has to identify importable header units somehow, doing it in the source seems to me to be the neatest solution.
>> what did I miss?
>
> If the header themselves identify if they're importable or not it
> means the build system needs to scan all headers (inside and outside
> the project, directly and transitively included) for that keyword in
> order to decide if a BMI needs to be produced or not. Particularly,
> that has to happen before the module dependency scanning, because a
> header becoming importable changes the overall shape of the dependency
> graph.

OK, I get that point…

> If, OTOH, between the package management and the build system, that
> information is available before-hand, and the list of importable
> headers is provided before the dependency scanning, then the
> dependency scanning knows to treat that include statement as an import
> and then the header unit will have its dependencies scanned
> independently.

… but, one might equally argue for any part of the dependency graph to be
pre-set by the user would reduce the load on dependency determination.

Iain

> Currently, I am of the opinion that identifying the importable headers
> must be handled in metadata, before the build system even starts
> anything.
>
> daniel