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

From: John Maddock (jz.maddock_at_[hidden])
Date: 2024-12-22 11:02:02

> Following this approach, dependencies are automatic. But this has a
> number of downsides:
> 1. At the moment, BMIs are built with the settings used to build Boost
> in the first place, which causes a lot of trouble.
> 2. The installation generates many more binaries than in the headers
> world. It is uncertain whether these binaries will be compatible if
> build flags change.
> 3. Some libraries support configuration macros. For instance,
> Boost::throw_exception supports BOOST_NO_EXCEPTIONS. This is used by
> other Boost libraries to support builds that disable exceptions. In
> the current world, the end user defines BOOST_NO_EXCEPTIONS in their
> code, includes the library, and everything works. Using a scheme like
> the one I suggested requires the user to build all the Boost modules
> using BOOST_NO_EXCEPTIONS, which is more involved than what we have
> today.

Yup, my feeling is that this puts us back where we were before 
auto-linking with msvc - which is to say with a huge number of hard to 
diagnose bug reports from folks with some obscure binary incompatibility.

OK, maybe not that huge yet, given modules niche usage, but hopefully 
growing over time.

At the risk of going off at a tangent, I would also suggest a "core" 
boost module containing all the commonly used small libraries - the 
lesson from the std module appears to be that bigger is better, at least 
up to some point.

> For this reason, it makes sense to consider whether there is a way to
> completely avoid the generation and installation of these binaries for
> header-only libraries, and follow a model similar to standard modules.
> In this ideal model, installing Boost with CMake would only install
> the headers and module code for each header-only library, and no
> binary artifacts. The consuming project would build both the BMIs and
> the objects containing the module initializers with the adequate build
> flags, as many times as required by the different targets.
>
> Ideally, the following syntax would work and do what I'm suggesting:
>
> # This does NOT work as of today
> add_library(boost_variant2 INTERFACE) # Don't build the library in the
> current project
> target_sources(boost_variant2 INTERFACE FILE_SET CXX_MODULES FILES
> modules/variant2.cxx)
> target_include_directories(boost_variant2 INTERFACE include)
> target_link_libraries(boost_variant2
>      INTERFACE
>        Boost::assert
>        Boost::config
>        Boost::mp11
> )

Having CMake do it all for us would be great, thinking out loud here, is 
there a way to publish a CMake code fragment that users could 
cut-and-paste into their own CMake file?  Still not ideal I know...

And finally... if anyone wants to experiment/road test a module with 
source, then Regex in develop is all module friendly now (but has no 
module build files).

Thanks for this!  Best, John.