C++ Logo

sg15

Advanced search

Re: [isocpp-sg15] [isocpp-core] [modules] wordings to allow build system to not always emit BMI for implementation partition units

From: Ben Boeckel <ben.boeckel_at_[hidden]>
Date: Wed, 14 Jan 2026 20:55:24 -0500
On Wed, Jan 14, 2026 at 13:38:51 -0800, Richard Smith wrote:
> The only purpose of a partition name is to allow the module unit to be
> imported. Is it really worthwhile for a compiler or a build system to
> expend extra effort to avoid a BMI in the case where the developer asks for
> a module unit to be importable but then doesn't import it? (I think this
> can reasonably happen due to the build configuration affecting which source
> files get built, but that seems like it should be pretty rare.)

Non-importability would require knowledge of all TUs that can "see" the
module in the first place. There's no rule that a module cannot span
libraries (CMake targets), so I don't think this is answerable in
general (the "normal" use case I've seen is for test code to be
"adopted" into the module to access otherwise-inaccessible APIs for
testing purposes). There's no way to do such optimizations in CMake as
scanning and collation is performed on a per-target basis with no
knowledge of consuming targets.

It's a lot of build-system work for minimal user gains IMO. We don't
even have comparisons of module strategies to even know how much perf is
even available to such an optimization, so I'd like to start picking up
the cash floating around in the air before we look for coins in the
cushions.

> On Wed, 14 Jan 2026 at 11:15, Ben Boeckel via Core <core_at_[hidden]>
> wrote:
> > Can we get an attribute like:
> >
> > module [[never_imported]] mod:part;
> >
> > to indicate this situation? If the scanner says no BMI will be
> > generated, the CMake (as it currently exists) has no qualms about such a
> > TU being in a non-`CXX_MODULES` file set.
> >
>
> We already have a (shorter) way of expressing that:
>
> module mod;
>
> What value would we get by adding another way to express the same thing?

That's basically my throughts prior to this thread. The one benefit that
has been expressed is that this adds a dependency on the module as a
whole. Other than that, yeah…not seeing much benefit. Certainly not
enough to not have the scanner also understand what is going on in the
first place. If the scanner reports "no BMI" (as the MSVC extension
does), then CMake as it exists today will have no qualms about the file
not being in a CXX_MODULES file set.

Thanks,

--Ben

Received on 2026-01-15 01:55:33