[Tooling] [isocpp-modules] Dependency information for module-aware build tools
Gabriel Dos Reis
gdr at microsoft.com
Tue Mar 5 17:59:30 CET 2019
> 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.
> 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?
>
> 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.
>
> --Ben
>
> [1]Though generating module map files for the scan step too…not so
> pretty.
More information about the Tooling
mailing list