Re: Interest for C++20 modules support of boost officially

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2025-01-13 20:33:35

On Mon, 13 Jan 2025, 17:05 John Maddock via Boost, <boost_at_[hidden]>
wrote:

> On 12/01/2025 20:51, Ruben Perez via Boost wrote:
> > Hi all,
> >
> > I finally have something workable regarding Boost and C++20 modules.
> > I've described it in detail in this article [1], but here's a rough
> > summary:
>
> Wow, thank you for this, that's a brilliant first step and proof of
> principle.
>

Thanks for your comments.

> I have a few comments, many of which are about things over which we/you
> have no control!
>
> 1) Are the CMake files usable with older CMake versions?
>

As far as I know, C++20 module support starts with CMake 3.28. And support
for import std (which the proposal uses) is still experimental. So I'd say
the answer to this question would be no, unfortunately.

> 2) The lack of Visual Studio generators for CMake is annoying: by far
> the best user experience is likely to come from Visual Studio
> integration as that handles module dependencies very well.
>

Yes, definitely. Windows CIs were more involved to set up because of this.

> 3) The need for a separate object file even for header only libraries is
> annoying, it leads to all kind of issues:
>
> 3a) We're going to end up generating an awful lot of module import
> initializer libraries.

> 3b) Using Boost with modules may be untenable, without using CMake to
> handle the dependencies: given that Boost.Whatever may have no end of
> dependencies all of which will need to be manually specified on the
> command like otherwise.  For a large project with multiple Boost
> dependencies things explode even further.  We're between a rock and hard
> place here, as I don't see a single monolithic Boost module as a good
> solution either.  But as things stand, building a trivial hello-world
> using-boost-as-module app from the command line could well be a no-no.
>

Yes, that's the case, unfortunately. Or, at least, without a build system
that understands the dependencies. A positive point is that running all of
our test suites in module mode should make us relatively confident in what
we ship. This can then be consumed from maybe build2 or other build system.

> 3c) I wonder what impact a dependency on lots of small modules will have
> on build times: both pre-compile module dependency-scanning phase, and
> linking to all those micro-libraries.
>

This is definitely something to look at, but I can't do it without
modularizing higher order libraries.

If this becomes a problem, we could think of creating a big
"boost.essentials" module that contains things like Core, ThrowException,
Mp11, Variant2 and System. I think this has been proposed before in the
context of headers. I'd defer this until we can measure this and the impact
is significant. For now, I've set all initializer-only libraries to be
STATIC, even when BUILD_SHARED_LIBS is ON.

> Best, John.
>

Thanks
Ruben.