As an example, look at this folder which:
https://github.com/facebook/folly/tree/master/folly/compress...
In short, these are compression tools. Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms.
Things don't have to be more or less generic.
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.
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
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.
These libraries generally have no third party dependencies. Because tracking down and compiling C++ dependencies is a dumpster fire.
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".
The presence of a defacto package manager completely changes the library dynamics.
I can't even link and test properly against GMP on Windows :/
It also predates the time period when people would whine about a lack of package managers.
As do a bunch of these libraries.