[Tooling] [isocpp-modules] Dependency information for module-aware build tools

Gabriel Dos Reis gdr at microsoft.com
Tue Mar 5 19:02:34 CET 2019


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


More information about the Tooling mailing list