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 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15