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

From: Chuanqi Xu (chuanqi.xcq_at_[hidden])
Date: 2024-12-19 12:27:12

> 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.
When we say installing modules, we’re saying installing the source files for the module interfaces, not the immediate products.
And for recompiling, it is the job of build systems. The story is, in a program, a module interfaces will only be compiled into an object once (and be linked). However, the module interfaces can be compiled into several pcms (BMIs) by the build systems with different configurations. So it likes headers in some aspect. 
This talk (https://www.youtube.com/watch?v=_LGR0U5Opdg&t=1662s <https://www.youtube.com/watch?v=_LGR0U5Opdg&t=1662s >) have some explanations
> 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 <https://github.com/boostorg/regex/blob/develop/doc/modules.qbk >, 
conceivably this could be enhanced by providing CMake and visual studio 
projects.
Excellent! I can’t believe it is so fast!
Thanks,
Chuanqi
------------------------------------------------------------------
From:John Maddock via Boost <boost_at_[hidden]>
Send Time:2024 Dec. 19 (Thu.) 20:01
To:Ruben Perez via Boost<boost_at_[hidden]>
Cc:John Maddock<jz.maddock_at_[hidden]>
Subject:Re: [boost] Interest for C++20 modules support of boost officially
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 <https://github.com/boostorg/regex/blob/develop/doc/modules.qbk >, 
conceivably this could be enhanced by providing CMake and visual studio 
projects.
Best, John.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost >