Hi Ben,

> On 13 Oct 2022, at 18:40, Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
>
> On Thu, Oct 13, 2022 at 09:41:27 +0100, Iain Sandoe via SG15 wrote:
>> * AFAICT, the build system can figure that a source depends on a
>> specific header, but it is also not able to determine if that header
>> is an “importable” one (except for the sub-set that are pre-defined to
>> be). Which means that we probably require that the user’s project
>> defines which headers are importable. That disconnects metadata from
>> the sources which is undesirable, if not a recipe for bugs.
>
> FWIW, the plan in CMake is to require metadata. If a header is not known
> to be importable by CMake, no scanning of it will be performed, no
> BMI-generating command will be in the graph, and therefore `import
> <some-header>;` will fail to be resolved at build time (without compiler
> magic going behind CMake's back, but that's just asking for ODR problems
> if you ask me) because CMake won't know to add it via the "module map"
> provided to compilation.

As of the current implementation, there is no intention that “standard C++”
modules perform any such compiler magic (although C++ “clang modules”
are free to, of course).

If such magic happens for the “standard" case, please file a PR.

A build system could choose to consume meta-data (like modulemap files) from
the source tree, of course.

—

I get Gaby’s assertion that ‘importable' is a property of use; however that does
cascade to properties of generation.

“import <some-header>;” is a statement by the user that the header should be
available as a HU.

That means it should be buildable as such (non-buildable then becomes the most
trivial test for ‘importability’).

I suppose that also means that a build system could take ‘import’ as an assertion
of importability and then generate the relevant build commands (also allowing for
include translation if the header is elsewhere “#include <>”’d).

Not lobbying for any of this … I do consider my original question as answered.

Iain