So the comment is really about the size of these libraries?

This is more of an artifact of companies that produced them, which use large monorepos, than the ecosystem itself.

That said, you can pick and choose which part of boost you use, just as you can pick and choose which part of Abseil/Folly you use.

> Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms.

Because C++ sucks and its dependency story is a nightmare. There are a few competing C++ package managers. They’re all relatively new and none of them are particularly popular.

The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project.

Compiling OpenSSL requires installing Strawberry Perl. This type of garbage of BS is the norm.

Source: C++ dev for 15 years

> The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project.

I think this has much more to do with templates than anything else. A template can only exist in a header.

Then there is also the performance benefit of inlining. (As well as performance hit of inlining, namely code size.)

There is a separate, much later movement/phenomenon of C (not C++) developed as header-only libraries, which by contrast I don't think there is nearly as good reason for except for that some people are confused at how a linker works. I have seen use of that technique advocated on Hacker News much more frequently than in production.

Header only and single file are slightly different. A headery library may include many many files. A single file or single header may be “header only” or it may have an impl define. People who prefer this distribution mechanism are generally ok with 1 header plus 1 cpp.

These libraries generally have no third party dependencies. Because tracking down and compiling C++ dependencies is a dumpster fire.

Or maybe they don't actually need the dependencies. There is a style of writing code to minimize dependencies and many people value this.

I would take the sqlite amalgamation as an example of good use of "few files, few dependencies". First off, it is above all a solid piece of work. It is distributed with one header file and one .c, even though it is developed as multiple files. Iirc the sqlite website cites a ~10% speed improvement or so due to the optimizer being able to do a better job across the whole library. In my opinion this is a better reason than "tracking dependencies sucks" or "omg too many files".

I'm pretty sure it's the (lack of) package managers.

The presence of a defacto package manager completely changes the library dynamics.

I can't even link and test properly against GMP on Windows :/

Sigh. Keeping sqlite as an example. On most Unix-like OSs (and even windows now) there is a dynamically linked sqlite managed by a package manager.

It also predates the time period when people would whine about a lack of package managers.

As do a bunch of these libraries.