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

From: Chuanqi Xu (chuanqi.xcq_at_[hidden])
Date: 2024-12-20 02:15:12

Hi Ruben,
 I think we’re in the same page except a few wording issues. e.g, I won’t call it as pre-compiled headers. But this doesn’t matter.
> 2. Boost.Url in the module world would install:
> * libboost_url.a, containing the same function definitions as above.
> * A boost_url.cppm file, akin to what headers are today.
> CMake would build a BMI from this file when a user needs to
import boost.url.
> In practice, this cppm file will likely be implemented in terms of the
> header files that we have today.
The libboost_url.a with modules support may have the same entities with original  libboost_url.a **plus** the module initializer.
And also, as discussed in other mail, the headers will be installed too.
> Unfortunately, CMake doesn't seem to have first-class support
for this, meaning that the user would need to figure out dependencies
manually.
What do you mean by figuring out dependencies manually? Do you mean, in cmake, the dependencies will be calculated if the libraries are linked? If yes, I feel it might be fine. Or did I misunderstand it?
Thanks,
Chuanqi
------------------------------------------------------------------
From:Ruben Perez via Boost <boost_at_[hidden]>
Send Time:2024 Dec. 19 (Thu.) 21:46
To:boost<boost_at_[hidden]>
Cc:Ruben Perez<rubenperez038_at_[hidden]>; John Maddock<jz.maddock_at_[hidden]>
Subject:Re: [boost] Interest for C++20 modules support of boost officially
> > 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.
If I understood the CMake developers and Chuanqi correctly (please let
me know if I didn't), you do install a library with the generated
object files, but you do not install the BMIs, as they're like
pre-compiled headers.
Let me explain how I understood it with two concrete examples. Take
Boost.Url as an example of a compiled library, and Boost.Regex as an
example of a header-only library.
1. Boost.Url today installs:
 * libboost_url.a, containing function definitions.
 * Headers, containing declarations.
2. Boost.Url in the module world would install:
 * libboost_url.a, containing the same function definitions as above.
 * A boost_url.cppm file, akin to what headers are today.
 CMake would build a BMI from this file when a user needs to
import boost.url.
 In practice, this cppm file will likely be implemented in terms of the
 header files that we have today.
3. Boost.Regex today installs:
 * Headers, containing declarations and definitions.
4. Boost.Regex in the module world would install:
 * A libboost_regex.a object, containing module initializers [1].
 For instance, if you have a singleton defining a Boost.System
error category,
 initialization code for the singleton would be emitted here.
 From the docs, it seems this object gets created even if no
 initialization code is required.
 * A boost_regex.cppm file, containing the bulk of the library, akin to
 what we provide using headers today.
My intention is doing some testing to see how much trouble would this
new libboost_regex.a library cause.
>
> 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.
What I described above is what you get if you use CMake's install()
function for a target containing C++20 modules. Ironically, this
doesn't apply for the standard library, which is always built by the
user. Unfortunately, CMake doesn't seem to have first-class support
for this, meaning that the user would need to figure out dependencies
manually.
I think the best model for our header-only libraries would be the one
used for the std module: we distribute the cppm files, and the module
gets built by the user. I will ping the CMake developers to see if
there is a way to handle this.
Thanks for your efforts here, John.
Regards,
Ruben.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost >