Skip to content

cxxmodules: Header unit support plan

Header units are more complicated than named modules because they are only ever read within the context of the consumer's flags. This means that they'll require synthetic targets even for non-IMPORTED targets. It should be noted that even named modules technically need these in the general case. This will require actually fleshing out logic in cmCxxModuleUsageEffects to detect when this matters.

This may end up needing to add new generator expressions for PRIVATE flags and defines to (though I suspect that $<*_INTERFACE> could be sufficient, but maybe another is needed for hiding flags even within a project such as $<SELF_TARGET_INTERFACE>).

Complications:

  • requires a collation step to "hide" the duplicately named modules provided by the base target itself (Visual Studio may need help here)
  • BMI-sensitive flag selections are probably better as a list of flag (patterns) known to not affect BMIs in order to be future-compatible
  • GCC does not support scanning imported header units (the BMI is needed at scan time with the current scanner)
    • may require preprocessor work (e.g., a state stack) to be able to "emulate" an import based on the textual contents of the found header

Current sketch of tasks:

  • implement cmCxxModuleUsageEffects
    • test via two targets using IMPORTED modules which use different standards themselves
  • create synthetic targets for non-IMPORTED named module usage
    • add test cases
  • add FILE_SET TYPE CXX_MODULE_HEADER_UNITS and create synthetic targets as needed
    • add test cases

CMake APIs:

  • FILE_SET TYPE CXX_MODULE_HEADER_UNITS
  • $<SELF_TARGET_INTERFACE> (maybe)
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information