10 Jan
2024
10 Jan
'24
8:07 a.m.
> Perhaps it's time to "get serious" about Boost "Modularization". > Basically this would mean that users download just the libraries (and > their dependencies) they actually intend to use. Of course this would > be a big project. But we've been working hard to try to move in this > direction. I would envision: > > a) user interested in boost download and locally test Boost "core" > b) for each library that a users is immediately interested in: > downloads, builds and tests the library (and it's dependencies) > c) as time moves on, users could update, replace, or delete their set > of libraries. > > This would in practice eliminate the concept of Boost version 1.84 > etc... and replace with Boost Serialization library version 1, ... > Boost would migrate from being a single/monolithic library to a group > of libraries with some explicit dependencies (on other boost librarys, > standard library or ?). While I agree that this modularization would be great and helpful especially for package managers (and their maintainers) I don't think distributing Boost libs as a loose collection of libraries is good for end-users/developers: - Boost libs do and should depend on other Boost libs especially for compatibility, bug fixes, improvements etc over the stdlib/compiler - Dependencies of Boost libraries are not obvious, especially the transitive ones making it hard to keep a working configuration - Dependencies might change with or without notice - It could make users believe they can mix and match Boost libraries of different versions while we do (and possibly can) only test a single configuration, i.e. the current state of master/develop/tagX of ALL libraries at that state - Although that "monolith" thing is a common complaint it also has an advantage: Once you have Boost already downloaded/set up you have something close to an "extended standard library" and are encouraged to look if what you need is already in one of the Boost libs you already have available instead of rolling your own. Having to go through the trouble of getting yet another set of dependent libraries is likely off-putting. Especially for the "with some explicit dependencies (on other boost librarys" part: Having the experience trying to just have a CMakeList (for CI testing) listing all direct and transitive dependencies of a Boost library "at the bottom" has shown that this is quite fragile and has led to trouble before. Pushing that to users isn't an idea I'm very fond off. And as a Boost maintainer I don't really want to care if some other Boost lib did or did not add or remove a dependency on another Boost lib. So having that list of "explicit dependencies" will be hard to keep up to date and valid at all times. Currently we can get away by saying "Boost is the dependency of Boost" Yes the dependency tool (e.g. used in CI) does a good job already and we could leverage that to create that list. It will still be changing and would need to be much more reliable, which means maintainers need to do more work getting their (direct) dependencies always(!) right and in the format that tool understands. However I do like the approach we currently have in CMake (and likely soon in B2) of not requiring a single "include/boost" folder but having the build system figure out (transitive) dependencies and required paths. Alex