Re: The state of modular Boost

From: John Maddock (jz.maddock_at_[hidden])
Date: 2025-04-16 09:19:43

On 14/04/2025 14:53, René Ferdinand Rivera Morell via Boost wrote:
> Hello fellow developers,
>
> As you might remember many months ago I started asking library maintainers
> to merge the build (and sometimes source) changes needed to make it
> possible to consume Boost libraries in a modular way. At this point a good
> number of libraries have merged those PRs. And there have been a pair of
> Boost releases containing those changes. But there is still work to do. So
> far, we have:
>
> * 119 PRs merged so far!
> * 4 PRs needing work before they can be merged.
> * 1 PR that was merged to master but never merged to develop.
> * 45 PRs that can be merged immediately.

First off, thank you for this effort, we really DO all appreciate this, 
however I do have some questions and concerns:

1) Documentation: recently CI for Boost.Math completely broke and 
despite 3 or us looking at it, we couldn't figure out why. Commenting 
out random stuff, I found that these project requirements were causing 
the issue:

project
 Â Â Â  : requirements
 Â Â Â Â Â  <library>/boost/math//boost_math
 Â Â Â Â Â  <library>/boost/multiprecision//boost_multiprecision
 Â Â Â Â Â  <library>/boost/test//included
 Â Â Â Â Â  <library>/boost/type_index//boost_type_index
 Â Â Â Â Â  <library>/boost/ublas//boost_ublas

If I removed them then everything started working again, so assuming 
that they were ancient cruft that was no longer needed I removed them.  
Woohoo, CI works again and we can get on with fixing some bugs, except 
now I realize these were part of the modular boost support code, so 
*probably* I've broken something else somewhere else, but I have no idea 
what.  Adding some boilerplate comments:

project
 Â Â Â  : requirements

 Â Â Â Â Â  # modular boost dependency list, please edit with care!

 Â Â Â Â Â  <library>/boost/math//boost_math
 Â Â Â Â Â  <library>/boost/multiprecision//boost_multiprecision
 Â Â Â Â Â  <library>/boost/test//included
 Â Â Â Â Â  <library>/boost/type_index//boost_type_index
 Â Â Â Â Â  <library>/boost/ublas//boost_ublas

 Â Â Â Â  # end dependency list

would have helped a lot.

2) Some of these dependencies appear to be added somewhat sledgehammer 
fashion: digging further the cause of the breakage was 
<library>/boost/test//included which was causing Boost.Exception *the 
library* to be built for every single target in the Jamfile, 
irrespective of whether it uses it or not (not one of them does, nor 
does Boost.Test I think), and for every single build configuration too.  
It was an <exception-handling>off test target that then caused 
Boost.exception to built with exceptions off which lead to a hard error.

3) There are other heavyweight dependencies, for example 
<library>/boost/math//boost_math is a binary target, if a testing target 
depends on it, then *it's already listed in the targets source* same for 
all other binaries.  Why do these need to be global project requirements?

4) This is terribly fragile, I had last week earmarked for squashing 
some bugs and pretty much all I've done is track down why CI was 
failing, first in Math then in TypeTraits and Config. It's not all your 
fault: deprecated test runners were a bit part of it, but it is awfully 
frustrating.  More to the point, as both the type_traits and math 
failures showed, random changes to other libraries modular-dependency 
lists can cause completely inscrutable failures downstream.  I can't 
help feeling that we need some tests for this modular code too - they 
may well exist already, but not within each libraries own test suite.  
Have I broken Math's modular support with the changes I made?  Genuinely 
I have no idea, and don't know where to look to find out.

I'm sorry if this comes across as overly negative, I don't want to stop 
you from modularising Boost, quite the reverse, and some of this may 
well be teething problems, but hopefully by raising this now, we can 
find a way to make this more robust and less inscrutable.

Thanks, John.