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

Essentially yes.

I don't see much value in suggesting that "import <unistd.h>;" should be rejected no matter what.

-- Gaby


-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Iain Sandoe via SG15
Sent: Thursday, October 13, 2022 12:21 PM
To: Ben Boeckel <ben.boeckel_at_[hidden]>
Cc: Iain Sandoe <iain_at_[hidden]>; Iain Sandoe via SG15 <sg15_at_[hidden]>
Subject: Re: [SG15] Header units again.

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

_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&amp;data=05%7C01%7Cgdr%40microsoft.com%7Cca23c37bab3345dad9b408daad501cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638012856840557784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=auBfwiMOOWzkx7yKK7kiv%2BvgEZDUpA3aaMLGpoV2c7A%3D&amp;reserved=0