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). 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