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.

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

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

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.

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

daniel