Re: Boost downloads and JFrog

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2024-01-10 08:07:28

> 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