On Mon, Dec 2, 2024 at 10:05 PM James via SG15 <sg15_at_[hidden]>
wrote:

> While working with C++ modules, I’ve noticed there’s currently no way to
> export macros from a module. Even if you wanted to opt into this, there’s
> no mechanism available.
>
> Given that macros are still essential for tasks like conditional
> compilation, this feels like a limitation. While macros can be
> controversial, they do help avoid repetitive and error-prone boilerplate in
> certain cases.
>
> Using headers is still an option, but it somewhat defeats the purpose of
> modules since each header needs to be parsed and preprocessed for every
> translation unit. PCHs can help, but they’re limited to a single PCH per
> project and require additional setup.
>
> I’d like to see a solution to this, but I’m unsure of the best path
> forward. Here are a few ideas I’ve considered:
> 1-) Allow exporting macros from modules (perhaps with a special directive
> like "#define_export").
> 2-) Enhance PCHs to be importable from consumed libraries. (meaning
> consumers will have both their own PCH(if there is one) and also consumed
> libraries' PCH precompiled)
> 3-) Introduce a mechanism for exporting macros from modules that are
> preprocessed only once.
>
>
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.

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.

- Michael Spencer