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.

On Mon, Jan 5, 2026 at 4:40 PM Chuanqi Xu via SG15 <sg15_at_[hidden]>
wrote:

> 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_[hidden]>
> Send Time:Mon, Jan 5, 2026, 16:34
> To:core<core_at_[hidden]>; 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). 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
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>