C++ Logo


Advanced search

Re: P2581R0: Specifying the Interoperability of Binary Module Interface Files

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Tue, 3 May 2022 12:48:24 +0000
I have a lot to say in this thread, but a request for the CMake folks:


Please, can we avoid "module headers" or "header modules" as terminology in the community?
We've settled on "header units". If we need something more than that, please let's work on it.

-- Gaby

-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Ben Boeckel via SG15
Sent: Tuesday, May 3, 2022 5:03 AM
To: Daniel Ruoso <daniel_at_[hidden]>
Cc: Ben Boeckel <ben.boeckel_at_[hidden]>; Daniel Ruoso via SG15 <sg15_at_[hidden]>; Tom Honermann <tom_at_[hidden]>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files

On Mon, May 02, 2022 at 20:50:14 -0400, Daniel Ruoso wrote:
> Em seg., 2 de mai. de 2022 ās 18:23, Ben Boeckel
> <ben.boeckel_at_[hidden]> escreveu:
> > For named modules, yes. I can't think of a reason why it would matter
> > myself, but I'm also not an implementor; I'm sure there are gremlins in
> > the details.
> For the scale of tens of thousands of projects, the prospect of having
> the same module unit be parsed in many different ways ending up in the
> same executable in something that we would like to avoid. Even though
> it can be made to work, I would prefer if the adoption of modules
> drives us into a path of reducing the difficulties we currently have
> with headers, not just reproduce them.

This is what I said back in 2019 at Kona: handle headers as standalone
units. If I handle `<vector>` with `_ITERATOR_DEBUG_LEVEL=1`, it *should
not matter* what the consumer says for the IDL; the `std::vector` type
will have debugging enabled. Since `<vector>` is the source for the
type, everything importing it should get the same view. Of course,
mixing `#include <vector>` and `import <vector>;` in the same codebase
can get confused, but that's nothing new for any `-D`-sensitive header.

> > For header units, it seems that some implementations
> > (Clang) may care about consuming target flags. I wish it to not be so,
> > but that's something for the Clang developers to (hopefully) figure out.
> I had a conversation with Michael Spencer today in C++Now, and my
> understanding is that it's not the compiler making those choices. The
> compiler just receives the module map, including header units. It is
> the build system that is deciding to parse the same header unit in
> different ways.

Oh, then that's fine. I was under the impression that Clang would reject
a BMI for a header that had different flags than expected. If we can
just give a BMI and it is trusted then that works how I'd expect it to
at least.

I suppose there is the danger of a setup like this:

import "shenanigans.h";
import something.else;

#define LE_SIGH 1
#define LE_SIGH 0

If the header unit BMI is created with `-DSOME_DASH_D_ONLY_FLAG`,
consumers need this flag as well to scan properly. It could be done with
a usage requirement to add `-DSOME_DASH_D_ONLY_FLAG`, but since this can
come from anywhere, not including it on the target means the consumer
also needs to not have it from anywhere else either

But I would argue instead that such a header should not be considered
importable anyways. Though it is likely undiagnosible as such beyond "an
imported preprocessor name affected imports" and saying "no, bad
developer". I don't think CMake can do that logic. I'm not even sure
compilers know enough to do that reliably either. So just more IF-NDR
funland I guess.

> My argument is that we should, instead, drive in the direction that
> header units will have an "owner", and that the parsing of those
> header units should be dictated by the library providing them (this
> depends on us being able to move forward in the package management
> space, but CMake may need some special way of saying "this imported
> target has this file set of headers" to decide how to parse them).

Yes, there is the `CXX_MODULE_HEADERS` fileset type for this. It just
has exactly zero backing implementation in CMake right now.

> And I make the same case here, that we have an opportunity to reduce
> the unintentional incoherences that we have with headers when we move
> to header units.

I hope we do not "move to header units". I want them to be a
transitional state on the way to named modules, not an end goal at all.
I'd much prefer we end with `import named.module;` and `#include
"config.h"` than have `import "config.h";` hairiness always be a
consideration (yes, I realize how unlikely this target is).

> Again, I think it would be really unfortunate if we just reproduce all
> the issues we have with headers when implementing modules (named or
> not).

100% agreed.

SG15 mailing list

Received on 2022-05-03 12:48:30