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";
#if LE_SIGH
import something.else;
#endif
```

```
#ifdef SOME_DASH_D_ONLY_FLAG
#define LE_SIGH 1
#else
#define LE_SIGH 0
#endif
```

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.

--Ben