C++ Logo

sg15

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 16:59:30 +0000


> 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.

Received on 2019-03-05 17:59:34