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

From: John Maddock (jz.maddock_at_[hidden])
Date: 2024-12-19 12:00:37

On 19/12/2024 11:32, Ruben Perez via Boost wrote:
>> 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 manyyou need to assume tha
> 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].

Correct me if I'm wrong, but in the modules world I don't think you can 
really install anything - you need to think of them as more like 
precompiled headers that are project specific and built as part of each 
individual project, you need to assume that changing *any* compiler 
option will break the module unless it is re-built.  That's why the msvc 
std module is built on a per-project basis.  Boost modules will be just 
the same I assume.

Meanwhile, I've cleaned up and merged Boost.Regex module support to 
develop if anyone wants to try it out.  There are rudimentary 
instructions here: 
https://github.com/boostorg/regex/blob/develop/doc/modules.qbk, 
conceivably this could be enhanced by providing CMake and visual studio 
projects.

Best, John.