Yeah, besides the terminology, I think we’re on the same page.
That is, the current wording doesn’t force build sytems to generate BMI for every importable module unit.
Thanks,
Chuanqi
------------------------------------------------------------------
From:core <core_at_lists.isocpp.org>
Send Time:Mon, Jan 5, 2026, 16:34
To:core<core_at_lists.isocpp.org>; SG15<sg15_at_[hidden]>
CC:Daniela Engert<dani_at_[hidden]>; Chuanqi Xu<chuanqi.xcq_at_[hidden]>; Ben Boeckel<ben.boeckel_at_[hidden]>
Subject:Re: [isocpp-core] [modules] wordings to allow build system to not always emit BMI for implementation partition units
Am 05.01.2026 um 08:11 schrieb Chuanqi Xu via Core:
 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
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.
Just to make sure I understand you correctly: with the (non-standard) term "module implementation partition unit" you mean [module.unit]#4.3 <http://eel.is/c++draft/module.unit#4.3 >, right? (In the teaching material of msvc, such a TU is called an "internal partition"). This is the thing to reach out for if you have a piece of code that you want to *import* into other parts of a module, but don't want to expose it in the interface. Every import requires unavoidably the existence of a BMI in the first place. If you learn from the dependency graph that none of the other TUs of a module ever imports said module-internal partition, then there is no requirement to produce a BMI for it IIUC. You may still want to compile the TU for object code that is required elsewhere, similar to a simple module implementation TU.
So, an internal partition *can* be imported elsewhere in the module, but *doesn't have to*. At worst, it's dead code without any noticable side effects.
 Thanks, Dani

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5