A related but not the same problem is can we try to skip the headers by emitting header guard macros (or #pragma once state) then we can import header wrappers modules easily.
e.g., we can put `import std;` to the top of every .cpp file easily. Currently it is not good due to some compiler defects. But even if the compiler defects are fixed, it is still bad since it will have slower compilation speed.
There is need in real world:(https://www.reddit.com/r/cpp/comments/1h2ktjz/applying_modules_to_projects_that_cant_use_modules/ <https://www.reddit.com/r/cpp/comments/1h2ktjz/applying_modules_to_projects_that_cant_use_modules/ >)
And maybe we design some syntax or interfaces to the library authors to let them say: this module is a wrapper for **these headers** and please emit header guard and `#pragma once` state for these headers. I believe this can speedup the process of modularization significantly.
Thanks,
Chuanqi
------------------------------------------------------------------
From: SG15 <sg15_at_lists.isocpp.org>
Send Time:2024 Dec. 4 (Wed.) 16:14
To:SG15<sg15_at_lists.isocpp.org>
Cc:Mathias Stearn<redbeard0531_at_[hidden]>; James<james.business.84_at_[hidden]>
Subject:Re: [isocpp-sg15] C++ Modules and Macros
Preface: I'm not saying we _should_ do this, just that it isn't quite as hard on the build system. There are other good reasons not to allow macros from named modules, and I say that as someone who actually likes them and thinks they are one of c++'s most important features for now.
I think with the current rules (possibly with cwg bug fixes to match intent) it is now impossible for macros to impact the module name:partition of a given file. This means that it is always possible to establish the mapping from name:partition to file in a single scan. After that, I think if modules exported macros, then the second scan pass could treat them just like header units (which don't require a BMI before scanning) after resolving the name to a file.
On Wed, 4 Dec 2024, 08.36 Ben Boeckel via SG15, <sg15_at_[hidden] <mailto:sg15_at_[hidden] >> wrote:
On Tue, Dec 03, 2024 at 12:01:25 -0800, Michael Spencer via SG15 wrote:
> Allowing named modules to export macros would make it significantly harder
> to actually build modular code. It would require a build system to be able
> to resolve named modules during scanning, meaning it can't use scanning to
> resolve named modules, which is what CMake currently does.
 To be more concrete, it means that it is impossible to reliably build
 this:
 ```c++
 import with_macro; // provides `some_imported_macro`…or does it?
 #ifdef some_imported_macro
 import macro_dependent;
 #endif
 ```
 In order to figure out how to build this, we would need to do multiple
 scanning phases:
 - scan once to get the "top level" imports
 - schedule those builds so their BMIs are ready
 - scan again to get any new imports that may be requested by macros from
 those modules
 - schedule those builds
 - scan again
 And so on until we get a fix point result. This requires either a static
 level of scanning for all TUs or the ability to dynamically add new
 scanning tasks during the build. If you thought modules as-is reduced
 the set of viable build systems by a lot already, adding this support
 cuts the population by the same factor again.
> The correct thing to do when you need macros is to use headers. The header
> defining the macros can also import the associated named module.
 Agreed. Macros are a preprocessor thing. Headers are a preprocessor
 thing. We've finally got a mechanism to put a fence around them. Please
 don't add a gate because as soon as there's a gate, the fence is
 meaningless.
 --Ben
 _______________________________________________
 SG15 mailing list
SG15_at_[hidden] <mailto:SG15_at_[hidden] >
https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >