Re: Compression libraries such as zlib and zstd ought to be first class boost libraries

From: Nigel Stewart (nigels.com_at_[hidden])
Date: 2024-05-04 23:37:22

>
> 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