Boost logo

Boost :

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-12-19 11:32:08


> I'm also not quite clear on how things will work on the CMake side. I can
> envisage the add_subdirectory case working, more or less, but what would
> (or needs to) happen when Boost is _installed_ via CMake, with module
> support enabled?
>
> And how will it then be consumed on the user side, after find_package?

I think this may be the most difficult part right now. Last time I
checked (as described in the cited articles), the workflow with CMake
was something like:

a) You add_library() and target_souces() using the new FILE_SET
CXX_MODULES feature. This builds a library (e.g. libboost_asio.a) and
a BMI. Note that even previously header-only libraries end up
generating compiled libraries in the modules world. The compiled
library contains code for global initializers, and is emitted even if
there are no global initializers [1].
b) You install() the library with its module bindings. This means that
you end up installing libboost_asio.a and any other files required to
generate the BMI for the Asio module (in this case, this would be Asio
headers). If the module contained implementation units (somehow akin
to .cpp files in today's world - apologies if the comparison is not
exact), these shouldn't get installed.
c) The user calls find_package() on the installed package, and calls
target_link_libraries() linking to the library installed in the
previous step. When doing this, CMake rebuilds the BMI, but not the
object files (libboost_asio.a). The BMI will be built with the same
cxxstd (I don't know about other properties) as the original library.
This is the point that generates questions for me, as it imposes many
more restrictions than the traditional header model [2]. On the other
hand, the CMake team seems to be working on enhancing this, but
without an ETA [3].

>
> Also, we're basically talking Clang-only here, right? GCC doesn't work and
> MSVC... may or may not work?

The approach where you #ifdef out standard includes and conditionally
export entities applies to both MSVC and clang. gcc has had
experimental support for modules for a couple of releases. libstdc++
has added support for the std module recently [4], but it hasn't been
released yet.

I'm going to experiment with Boost.CMake and modules to see if we
could produce an installed Boost containing only the libraries that
support modules. And see how much trouble point c) would cause us. I'm
particularly worried about libraries like Asio, that radically change
based on macros.

[1] https://clang.llvm.org/docs/StandardCPlusPlusModules.html#module-initializers
[2] https://crascit.com/2024/04/04/cxx-modules-cmake-shared-libraries/
[3] https://discourse.cmake.org/t/advice-on-c-20-modules-boost/10641/5
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk