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.