Can you give an example of "header units"? I can't find an example of that.
If I understand correctly, you mean I can have a header unit "foo" which
can be imported from "main.cpp" and "main.cpp" can access macros, right?
```cpp
import foo;
constexpr int val = SOME_MACRO_FROM_FOO;
```

On Tue, Dec 3, 2024 at 9:39 AM Daniela Engert <dani_at_[hidden]> wrote:

>
> > James via SG15 <sg15_at_[hidden]> hat am 03.12.2024 07:04 CET
> geschrieben:
> >
> >
> > 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.
>
> This is not exactly correct: the mechanism to export macros from modules
> is called "header units".
>
> > 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.
>
> The "easy" way around such perceived limitations is wrapping the module
> into a tiny header which implicitly imports the module, and brings a set of
> macros with it.
>
> > 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.
>
> My experiences from working with modules for the past 6 years, and having
> them in production for nearly 3 years, never gave rise to advocate
> *language* changes similar to your ideas. But may be my use cases are just
> different.
>
> Dani
>