C++ Logo


Advanced search

Re: Header units again.

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Thu, 13 Oct 2022 17:51:36 +0000
"import <some-header>;" is arguably the marking of such header as "importable".

I believe it is unfortunate that the term "importable" made it into the standards text as it creates an endless source of confusion.
It is not a property that is determinable before the import is executed, other than by fiat.

-- Gaby

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

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.

This also goes for standard library headers (though this list can be
provided by CMake itself once header units are supported beyond "not

SG15 mailing list

Received on 2022-10-13 17:51:39