A major pain point are libraries who keep bundling well known libraries in their builds, or even worse: Downloading them during configure/build steps. Especially when the version they use is a patched variant of some upstream source.
Alex, Historically that's been typical for supporting Windows builds. I'm guilty of that, but it turns out that Windows users are important. The paradigm of using system-installed libraries is pretty much out the window there. I've done a lot of cross-platform C++ over the years which means trying to minimise platform-specifics where possible. The less we depend on the customer's system, the better chance we have of running there, out of the box.
Hence we (the community behind the "build software") spend considerable effort in making such software use the already installed (sometimes called "system") libraries.
Yes. And typically at work I'm coaxing builds to use _our_ static libraries instead. I don't think it's the most common use case, but I do consider it legitimate, even if the tools are defaulting otherwise. Disabling shared libtiff target breaks the build, for example. Needs patching. So it goes.
So bundling something like zlib with Boost not only increases the maintenance cost of Boost
Yes, that's a consideration. A broader difficulty I'm having with zlib in particular is poor cmake support. Rolling that into the boost cmake scheme is appealing, at least we'd have confidence with that. Possibly I can swap zlib out for zlib-ng, purely because the cmake is done right. But I agree that typically on Linux boost ought to use the shared zlib that is always there, by default.
For use cases like using a specific version of some specific library in an environment where compatibility between libs is otherwise handled
We want our Linux binaries to match our Windows binaries, including dependencies. A new Ubuntu might have notions of modernisation, but that is our choice and responsibility. On the other side of that coin we can use the current version of boost on older Ubuntus, and that is good. Still using Ubuntu 20.04 for production, but have no desire to be tied to boost 1.71.0. Which is all to say we have reasons to do things a little differently. And it would be nice for boost to be "batteries included" for static linking in particular. But it's hard to say how broadly that would be valued or appreciated. - Nigel Stewart