Just as the compiler is permitted to translate #include to import (
https://eel.is/c++draft/cpp.include#7), -include can also import a header
unit and avoid repeated preprocessing just like PCH.

If you want macros, you want a header, whether included or imported as a
header unit; as Daniela says, a small header that imports a module is worth
considering.

I've been considering a built-in macro like __has_include for imports, so
that a header can choose to skip non-macros if its contents are available
from a module. My initial thought was to ask if 'import foo' would
succeed, but that seems too dependent on the state of the build, so now
lean more toward asking whether 'import foo' has already happened.

On Tue, Dec 3, 2024 at 4:19 AM James via SG15 <sg15_at_[hidden]> wrote:

> That's an ergonomic solution that I wasn't aware of. Thanks for that.
> But still this doesn't prevent the specified file from being processed
> multiple times. You still need PCH for that. Ideally "export import
> <foo.h>;" would handle everything.
> In terms of build performance, my header file doesn't take that much, so I
> can ignore it for my own use case. But that's still an issue in my opinion.
> It's nice of modules to not leak macros, but it also shouldn't kill macros
> in my opinion
>
> On Tue, Dec 3, 2024 at 11:51 AM Peter C++ <peter.cpp_at_[hidden]> wrote:
>
>> James
>>
>> have you considered the compiler command line option -include file for
>> your problem?
>>
>> I know, this doesn't show in the source, but could come handy for global
>> macros.
>>
>> sent from a mobile device so please excuse strange words due to
>> autocorrection.
>> Peter Sommerlad
>> peter.cpp_at_[hidden]
>> +41-79-432 23 32
>>
>> On 3 Dec 2024, at 09:32, James via SG15 <sg15_at_[hidden]> wrote:
>>
>> 
>> I see. My issue is basically "export import <foo.h>;" is not working as
>> expected. Meaning every single file that needs to use that macro must know
>> about foo.h, a module can't recursively export them. Also as far as I
>> understand, that syntax still requires foo.h to be contained in an include
>> path or the same directory as the current file, you don't need to know
>> anything about file structure or have include paths in normal module files.
>> These might seem trivial, but consider you have some globally required
>> macros.
>>
>> On Tue, Dec 3, 2024 at 11:14 AM Daniela Engert <dani_at_[hidden]> wrote:
>>
>>>
>>> > James <james.business.84_at_[hidden]> hat am 03.12.2024 08:50 CET
>>> geschrieben:
>>> >
>>> >
>>> > Can you give an example of "header units"? I can't find an example of
>>> that.
>>>
>>> you might want to look at http://eel.is/c++draft/cpp.import or
>>> http://eel.is/c++draft/module#import-5
>>>
>>> > 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;
>>> > ```
>>>
>>> Pretty close, you need to massage your import a bit
>>>
>>>
>>>
>>> >
>>> > 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
>>> > >
>>>
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>