C++ Logo


Advanced search

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

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Tue, 5 Mar 2019 18:02:34 +0000

— 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

Received on 2019-03-05 19:02:40