On Tue, Jan 13, 2026 at 11:19:32 +0800, Chuanqi Xu wrote:
> As the author of CMake modules and who said the current wording has a
> bug/defect, would you like to comment to explain why do you think the
> current wording has a bug/defect for it?
> CC Jens as the chair of CWG.

This was not me (I am `mathstuf` on Reddit). It is, however, a fellow
Kitwarean. He's not available right away, so I am speaking for myself
here based on what he wrote.

>From Chuanqi's blog post:
> However, in practice, there is a small issue for CMake users with this
> approach. Currently, CMake requires all module implementation
> partition units to be listed in CXX_MODULES_FILES, which causes CMake
> to generate a BMI for each of them. This is a waste of time. In our
> example, network.cpp, common.cpp, and util.cpp are designed not to be
> imported by any other unit, a fact that the programmer can guarantee
> and intends.

>From linked Reddit reply:
> As discussed upstream, this is a standard bug and there's unlikely to
> be any movement on it unless something changes in the standard.
>
> The standard has no way to advertise a "non-exporting" partition unit.
> It is assumed all partition units export, thus all partition units
> must generate a BMI. Notably, clang makes the same assumption whenever
> it sees a .cppm extension.
>
> The MSVC behavior (absent /internalPartition) is simply broken and
> non-conforming

IMO, if you have a non-exported partition that you don't want exported,
remove the partition name. It can (must) then be listed outside of a
`CXX_MODULES` file set and won't make a BMI (whatever the costs may be).
The standard already has a mechanism to do the "part of a module, but
not making a BMI". Why do we need another subflavor of translation unit?

>From Chuanqi's Reddit reply:
> For build system, my confusion part is, in bazel, it works fine if we
> put the module unit in the `srcs` field instead of the
> `module_interface` field. Given the support of modules in bazel
> generally follows cmake, I don't understand why cmake can't make the
> same behavior.

CMake sees that the scanner says "makes a BMI named X", compares against
its notes that it isn't expecting a BMI and assumes user error.

--Ben