On 5/3/22 08:48, Gabriel Dos Reis via SG15 wrote:
> I have a lot to say in this thread, but a request for the CMake folks:
>
>> CXX_MODULE_HEADERS
>
> 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.

Absolutely. Also, in some contexts 'modules' can refer to both 'named
modules' and 'header units', and in others just the former. It is best
to be unambiguous.

nathan

>
> -- 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";
> #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
> _______________________________________________
> 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%7Cd19df1f619e343dc59d108da2cfce485%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637871761919372019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=6QMgUrMbk71TmvI7wd5ko2c06TQfMwRZSNXV%2FFXIHM8%3D&amp;reserved=0
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

-- 
Nathan Sidwell