On Tue, Mar 05, 2019 at 16:59:30 +0000, Gabriel Dos Reis wrote:
>
>
> > On Mar 5, 2019, at 8:29 AM, Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
> >
> >> On Tue, Mar 05, 2019 at 16:14:19 +0000, Gabriel Dos Reis wrote:
> >> Header units name (in source code) exactly a header or a header file
> >> that can be found by #include. The path to the actual artifact that
> >> is loaded is different, since it is a BMI.
> >
> > So even scanning might need BMIs generated?
>
> I don’t think that is what I said or implied.

Thanks for the clarification. I probably drew something causal between
"found by include" and "artifact that is loaded".

> > That might be a problem, but
> > CMake (and other tools) can probably ensure that header unit generation
> > get into the build graph properly[1], but this is unlikely to be optimal
> > considering what I was hoping CMake would be able to do with
> > unreferenced header unit modules (not making BMIs for them at all).
>
> I believe that is possible. Why would that not be possible?

The optimization would not be possible if BMIs were required before
scanning could occur since scanning could have needed any BMI from a
specified header unit.

> > Is it feasible for scanning to not do that and instead load it as if it
> > were `#include` and dropping non-exported macros at the end of the
> > import?
>
> That is exactly what I would expect, and what we talked about on the
> first telecon. Especially for matters such as finding macros that are
> made available by a header unit import.

This all sounds OK to me then (Kitware wasn't at the first tcon).

--Ben