C++ Logo

sg15

Advanced search

[isocpp-sg15] [modules] wordings to allow build system to not always emit BMI for implementation partition units

From: Chuanqi Xu <chuanqi.xcq_at_[hidden]>
Date: Mon, 05 Jan 2026 15:11:39 +0800
Hi Experts,
 The motivation of the mail comes from https://www.reddit.com/r/cpp/comments/1pzbnzy/comment/nww0aaw/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button <https://www.reddit.com/r/cpp/comments/1pzbnzy/comment/nww0aaw/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button > (I’ll redescribe this if you are not interested enough).
 CMake didn’t allow users to not list module implementation partition units out of CXX_MODULES_FILES, which will generate BMIs. CMake developers said, this is required by the standard. Since the spec says, the module implementation partition units are importable. But I don’t think so. I think “can” be imported doesn’t mean it “must" be imported.
 But CMake developers said this is a standard bug. So I want clarification from the wording group and SG15 group (as this relates to build systems), is this a wording bug? If yes, do we want a paper for it or a defect report? What’s the suggested wording?

# Background
I described the full background in my blog: https://chuanqixu9.github.io/c++/2025/12/30/C++20-Modules-Best-Practices.en.html#use-module-implementation-partition-units-not-module-implementation-units-to-implement-interfaces <https://chuanqixu9.github.io/c++/2025/12/30/C++20-Modules-Best-Practices.en.html#use-module-implementation-partition-units-not-module-implementation-units-to-implement-interfaces >
The story is, the module implementation unit will import the primary module interface implicitly. And all the module interface partition unit requries to be exported by the primary module interface. ([module.unit]p3). Then it implies that, if we change any interface units, all the module implementation units will be rebuilt. This is unacceptable in practice. e.g., internally for a module, we may have hundreds of implementation files. Then if we use module implementation units for all of them. The recompilation problem is unacceptable.
But I got the solution. It is, use module implementation partition units to implement things. Then every thing solved. But cmake didn’t allow users to treat module implementation partition units as non-module srcs (https://gitlab.kitware.com/cmake/cmake/-/issues/27048 <https://gitlab.kitware.com/cmake/cmake/-/issues/27048 >). So users have to suffer from additional serializing cost. Then it is the beginning of the mail. The end users have the ability to design and know which units won’t be imported.
Thanks,
Chuanqi

Received on 2026-01-05 07:11:45