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

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-12-22 11:51:01

On Sun, 22 Dec 2024 at 12:02, John Maddock via Boost
<boost_at_[hidden]> wrote:
>
>
> > 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.

I think this is a completely valid concern. Once I have a minimal
prototype working, I will try to investigate how much of a problem
this is.

>
> 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 now, I'm doing a single module per library, because it maps much
easier to the current CMake infrastructure. Given the current state of
modules, I don't want to waste too much time.

>
> > 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...

I've had the same thoughts, too. Best I can think of is a CMake
function. For instance:

# In the user's CMakeLists.txt
# This means "I want to build the Boost.Variant2 module and its dependencies.
# Create a target called my_variant2_module
boost_add_cxx20_module(variant2
  TARGET_NAME my_variant2_module
)

# Now use the module
add_executable(main main.cpp)
target_link_libraries(main PRIVATE my_variant2_module)

There are at least 2 unsolved problems here:
1) How does the user specify build options for the module? That is,
how do they specify that they want C++23, a certain visibility, and
BOOST_DISABLE_EXCEPTIONS? This is a problem because options must be
specified not only to the my_variant2_module, but to all the dependent
Boost modules (e.g. Boost::assert and Boost::mp11, in this case).
2) How does this work for compiled libraries?

A possibility I can think for 1) is making boost_add_cxx20_module
accept a CMake interface target with the user options. All targets
created by boost_add_cxx20_module would be linked to this target:

# An interface target to specify that we want BOOST_DISABLE_EXCEPTIONS
add_library(my_options_lib INTERFACE)
target_compile_definitions(my_options_lib INTERFACE BOOST_DISABLE_EXCEPTIONS)

# Create the Boost modules, defining BOOST_DISABLE_EXCEPTIONS
boost_add_cxx20_module(variant2
  TARGET_NAME my_variant2_module
  LINK_TO my_options_lib
)

I'm pretty sure this approach has problems I'm not seeing right now.
I'm reluctant to this kind of ad-hoc approach - it'd be best if CMake
did it.

I haven't thought about 2) yet.

>
> 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).

If I have the time, I will include it in the prototype, although I
promise nothing yet. I'm trying to get some of the foundational
libraries (assert, throw_exception, config, core and mp11) and their
tests building for both compilers before anything else.

>
> Thanks for this!  Best, John.

Thanks,
Ruben.