[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