Terrific!

— Gaby

> On Mar 5, 2019, at 9:58 AM, Ben Boeckel <ben.boeckel_at_kitware.com> wrote:
>
>> 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_kitware.com> 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