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