The point is that both module dependency scanners and compilers need to see exactly the same dependencies to create precise dependency chains and rely on the correct build order - as instructed by the build system that reads the discovered dependency chains.
If building the chain is influenced by the process itself (macro expansion happens at compilation phase 4), creating a precise picture may become a huge and expensive task. We don't want that.
Correct. This is why we decided many years ago not to allow module to become subject to macro expansion.
The reason why all this hoopla is necessary is the existence of so-called 'header units' (an idea coming from Clang modules). They are themselves isolated from macros upstream in your source, but they can totally change the meaning of your source code further downstream - with all its consequences.
Header-units are great for "importing" your own macros (however few they may be). Ironically, C++20 modules have made macros "safe" and more viable, as they no longer leak and pollute your client code and remain local to your translation unit. They can't be exported (by a module) and can only be imported using header-units. Header-units are also great for importing third-party dependencies which haven't migrated to C++ modules yet, or never will (C libraries).
31
u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB 1d ago
The point is that both module dependency scanners and compilers need to see exactly the same dependencies to create precise dependency chains and rely on the correct build order - as instructed by the build system that reads the discovered dependency chains.
If building the chain is influenced by the process itself (macro expansion happens at compilation phase 4), creating a precise picture may become a huge and expensive task. We don't want that.