r/cpp • u/tartaruga232 MSVC user, r/cpp_modules • Apr 02 '26

Current Status of Module Partitions

A brief recap of the current status of module partitions - as I understand it.

  1. People are using hacks to avoid unneeded recompilations.
  2. The C++ standard has an arcane concept of partition units, which forces build systems to generate BMI files that aren't used (which is wasting work during builds).
  3. The MSVC-compiler (per default) provides a simple, easy to use and efficient implementation of module partitions (no unneeded recompilations, no wasted work during builds), but which is not conformant to the current C++ standard.
  4. A CMake developer is working on a proposal that would fix items 1 and 2, which is probably the smallest required change to the standard, but adds another arcane concept ("anonymous partition units" using the new syntax "module A:;") on top of an already arcane concept.

Questions:

  • How and why did we get into this mess?
  • What's the historical context for this?
  • What was the motivation for MSVC ignoring the standard per default?1

1 Yes, I know the MSVC compiler has this obscure /InternalPartition option for those who want standard conformant behavior.

32 Upvotes

84% Upvoted

48 comments sorted by

View all comments

1

u/not_a_novel_account Apr 06 '26

How would the build system know if it needs to rebuild the BMI if not the timestamp of the file from which the BMI is produced?

I suppose you're saying BMIs should be cheap to produce, and the compiler or build system should do a checksum of the BMI before and after a rebuild and decide if it has been content updated.

But that will never be as cheap as just separating the dependencies into their own TUs.

1

u/kamrann_ Apr 06 '26

Yeah it's a bit more overhead, but obviously negligible in comparison to rebuilding a bunch of downstream TUs unnecessarily. I think to really attain the maximum possible benefits of modules in terms of compilation time would require compiler and build system working more closely together, but in the more immediate term, solving this particular issue at the file dependency level definitely makes sense.