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