On Mon, 13 Jan 2025, 17:05 John Maddock via Boost,
On 12/01/2025 20:51, Ruben Perez via Boost wrote:
Hi all,
I finally have something workable regarding Boost and C++20 modules. I've described it in detail in this article [1], but here's a rough summary:
Wow, thank you for this, that's a brilliant first step and proof of principle.
Thanks for your comments.
I have a few comments, many of which are about things over which we/you have no control!
1) Are the CMake files usable with older CMake versions?
As far as I know, C++20 module support starts with CMake 3.28. And support for import std (which the proposal uses) is still experimental. So I'd say the answer to this question would be no, unfortunately.
2) The lack of Visual Studio generators for CMake is annoying: by far the best user experience is likely to come from Visual Studio integration as that handles module dependencies very well.
Yes, definitely. Windows CIs were more involved to set up because of this.
3) The need for a separate object file even for header only libraries is annoying, it leads to all kind of issues:
3a) We're going to end up generating an awful lot of module import initializer libraries.
3b) Using Boost with modules may be untenable, without using CMake to handle the dependencies: given that Boost.Whatever may have no end of dependencies all of which will need to be manually specified on the command like otherwise. For a large project with multiple Boost dependencies things explode even further. We're between a rock and hard place here, as I don't see a single monolithic Boost module as a good solution either. But as things stand, building a trivial hello-world using-boost-as-module app from the command line could well be a no-no.
Yes, that's the case, unfortunately. Or, at least, without a build system that understands the dependencies. A positive point is that running all of our test suites in module mode should make us relatively confident in what we ship. This can then be consumed from maybe build2 or other build system.
3c) I wonder what impact a dependency on lots of small modules will have on build times: both pre-compile module dependency-scanning phase, and linking to all those micro-libraries.
This is definitely something to look at, but I can't do it without modularizing higher order libraries. If this becomes a problem, we could think of creating a big "boost.essentials" module that contains things like Core, ThrowException, Mp11, Variant2 and System. I think this has been proposed before in the context of headers. I'd defer this until we can measure this and the impact is significant. For now, I've set all initializer-only libraries to be STATIC, even when BUILD_SHARED_LIBS is ON.
Best, John.
Thanks Ruben.