On Sunday, 18 April 2021 14:00:01 CEST [email protected] wrote: > >> So perhaps that is the best way to avoid having to deal with ABI/API > >> breakage... > >> After that it is up to the maintainers of the dependant packages to > >> update their package and start using boost-1.75. > > > > There is the implicit assumption that a patch that updates > > boost for all the dependent ports should also provide fixes > > if those ports fail to build after the update. That is > > the major task. > > There are "only" 490 ports that have boost in their Makefile.
Compare this to CMake, which has about 1900 direct consumers. While there's less ABI-breakage and more configure- and build-time breakage, a CMake update looks like this: - build all the consumers with the current version of CMake - fix the ones that don't build, or mark BROKEN - bump CMake locally - build everything again - fix the ones that don't build The actual CMake parts are the easy bits. Dealing with 15-year old C++ code that happens to use CMake and falls over for totally unrelated reasons is the real time sink. Ceph, too, is one of those things that eventually gets added to my ignore list as "doesn't build in any recent ports checkout": /usr/local/bin/ld: ../../../lib/libkv.a(LevelDBStore.cc.o): (.data.rel.ro._ZTI17CephLevelDBLogger[_ZTI17CephLevelDBLogger]+0x10): undefined reference to `typeinfo for leveldb::Logger' I fix what I can, send mail to maintainers when I can't and so we hope that progress happens. [ade]
signature.asc
Description: This is a digitally signed message part.
