> 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?
This is the problem. It then requires the users to pay for the additional cost for generating BMIs. In some degree, it violates the zero-abstraction rule.
I can understand that CMake didn’t optimize this due to human resources or what ever reasons. But I think we need to be on the same page that we should allow it.
> Sure, if the build system can determine that an importable module unit isn't ever actually imported, then it can optimize away building the BMI.
This seems like an "as-if" issue, unobservable by a conforming program. The standard doesn't say anything about build system artifacts.
OTOH, BMI generation seems like a small overhead as a side effect of compilation, so it's unclear to me why avoiding it is a high priority.
Thanks for clarification. I don’t think it is a high priority. But I do think it is a problem of CMake’s implementation. And a cmake dev says the root cause is the spec wording. That’s why I sent this.
Thanks,
Chuanqi
------------------------------------------------------------------
From:core <core_at_[hidden]>
Send Time:Wed, Jan 14, 2026, 03:03
To:Chuanqi Xu<chuanqi.xcq_at_[hidden]>
CC:Ben Boeckel<ben.boeckel_at_kitware.com>; core<core_at_[hidden]>; SG15<sg15_at_[hidden]>; Jens Maurer<jens.maurer_at_[hidden]>
Subject:Re: [isocpp-core] [modules] wordings to allow build system to not always emit BMI for implementation partition units
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
_______________________________________________
Core mailing list
Core_at_[hidden]
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core <https://lists.isocpp.org/mailman/listinfo.cgi/core >
Link to this post: http://lists.isocpp.org/core/2026/01/19209.php <http://lists.isocpp.org/core/2026/01/19209.php >