Linux package managers and Homebrew don't solve it, not even close. In fact, their fragmentation makes the problem worse.
If I write a C library and someone wants to use it in their library or application, they have three choices:
1. Add it as a build dependency of their project. This is a huge pain.
- First of all because most build systems are extremely fiddly and poorly designed, so adding the dependency is usually harder than it should be. For example, because CMake, which everyone seems to be using these days, can't produce sensible Visual Studio projects, one project I've worked on maintains separate CMake and Visual Studio build systems - which means that making any moderately complicated changes to the build requires me to either manually edit the VS XML files, send the result to the trybots, and pray it works, or boot a Windows VM. That's just an example; I don't know how representative in the sense that other projects also use that dual build hack, but from struggling with CMake, autoconf, and other build systems, I'd say it's representative in the sense that build systems will always find some stupid way to break and waste your time. Awful. Any alternative is worth consideration.
But let's say we found an alternative that's not a package manager, and ended up with a nice clean system where adding a dependency on a given pkg-config file is just a matter of a few lines and will just work, including for users on weird systems. Yeah.
- Second because the user now has to manually download all the dependencies, and manually upgrade them when they get out of date. Which means you don't want to release too many upgrades, even if you're trying to do rapid development. It's nice that this is possible, I guess, but it's a real pain.
- That is, unless it's in their distribution or system package manager of choice. But going to 10 different Linux distributions, Homebrew, and maybe MacPorts for good measure (and leaving Windows users to rot), and asking each of them nicely to add your library, is not exactly a pleasant experience. Maybe they will add it themselves if an application depends on it, once your library is actually popular rather than a proof of concept. (A bit of a chicken and egg situation.) And then maybe stable Linux users will actually be able to download it in a year or so, but will always be out of date. Of course, if the project using your library wants to be on its bleeding edge, their developers can't do this themselves - they have to go the manual route.
This also doesn't really work for micro-libraries, which I'll elaborate on in a bit.
So it's not surprising that two other approaches are common:
2. "Vendor" your codebase into their codebase, either with something like git-submodule or just by copy and paste. Typically this requires them to figure out how to build your code with their build system. Works okay, but is basically just a poor man's package manager - it has none of the advantages of the previous method, such as systemwide package tracking and upgrades (either by the system package manager or the user manually remembering to do it!), reduction of fragmentation, etc.; and it is more work to maintain.
3. Don't bother with your library at all; just reimplement whatever they want themselves (in a poorer fashion).
It's hard to quantify how much this happens, but in my experience, C++ projects do seem to have a bias toward building up little piles of basic utilities rather than reaching for a library. At the other extreme would be node.js and NPM - this post, as well as a Debian thread from a few months ago it belongs to, containing much handwringing about how to fit it into their system, is a good read:
(Spoiler: It's the build dependency graph for building jQuery, which contains some 491 entries, although it lists packages multiple times when they are referenced by multiple dependencies.)
Some NPM packages are literally 5 lines of code. Arguably still better than copy and paste... maybe...
I don't think C/C++ need to go there; most languages with package managers don't. But it's a good example of how the presence of packaging tools, as internalized into a programming language's culture, significantly changes the way people write code in those languages. And I think C/C++ could be a lot more pleasant if it were easier to reach for utilities outside of the standard library. (Especially pure C, which lacks an equivalent of the STL in its standard library - while the language may prevent writing data structures as neatly as in C++, you can still express some generalized high level structures pretty well and efficiently; and I think the standard library is partly to blame for the fact that people usually don't, instead building half-assed special-purpose data structure implementations every time one is required.)
...
I know, the idea of having a different package manager for every language sounds awful. It is awful, both for the user who needs to remember how each one works, and for the developer who's screwed if they want to depend on something written in a different language. I'd be quite interested in the idea of building something that feels like a language package manager, but is actually just Nix or something with some useful defaults...
But I'm starting to be convinced that having nothing at all is worse.
You allude to the complexity of C builds. While real, a huge fraction of this is not caused by any inherent difference between C and interpreted languages, but simply the diversity and general mess of C build systems. (Of course, some low level programs really do require complex build processes, and those programs are more likely to be written in C than Ruby, but those are the minority.)
And this is something a package manager can significantly, simply by providing less flexibility and therefore more standardization. Ideally, if you can build one package from the package manager, you can build 'em all.
Somewhat belated disclaimer: I haven't given conan.io more than a quick look, so I don't know how well it actually solves any of the preceding, heh. But I've wanted to see a good C package manager for a while, and I fully intend to check this one out when I have the chance.
If I write a C library and someone wants to use it in their library or application, they have three choices:
1. Add it as a build dependency of their project. This is a huge pain.
- First of all because most build systems are extremely fiddly and poorly designed, so adding the dependency is usually harder than it should be. For example, because CMake, which everyone seems to be using these days, can't produce sensible Visual Studio projects, one project I've worked on maintains separate CMake and Visual Studio build systems - which means that making any moderately complicated changes to the build requires me to either manually edit the VS XML files, send the result to the trybots, and pray it works, or boot a Windows VM. That's just an example; I don't know how representative in the sense that other projects also use that dual build hack, but from struggling with CMake, autoconf, and other build systems, I'd say it's representative in the sense that build systems will always find some stupid way to break and waste your time. Awful. Any alternative is worth consideration.
But let's say we found an alternative that's not a package manager, and ended up with a nice clean system where adding a dependency on a given pkg-config file is just a matter of a few lines and will just work, including for users on weird systems. Yeah.
- Second because the user now has to manually download all the dependencies, and manually upgrade them when they get out of date. Which means you don't want to release too many upgrades, even if you're trying to do rapid development. It's nice that this is possible, I guess, but it's a real pain.
- That is, unless it's in their distribution or system package manager of choice. But going to 10 different Linux distributions, Homebrew, and maybe MacPorts for good measure (and leaving Windows users to rot), and asking each of them nicely to add your library, is not exactly a pleasant experience. Maybe they will add it themselves if an application depends on it, once your library is actually popular rather than a proof of concept. (A bit of a chicken and egg situation.) And then maybe stable Linux users will actually be able to download it in a year or so, but will always be out of date. Of course, if the project using your library wants to be on its bleeding edge, their developers can't do this themselves - they have to go the manual route.
This also doesn't really work for micro-libraries, which I'll elaborate on in a bit.
So it's not surprising that two other approaches are common:
2. "Vendor" your codebase into their codebase, either with something like git-submodule or just by copy and paste. Typically this requires them to figure out how to build your code with their build system. Works okay, but is basically just a poor man's package manager - it has none of the advantages of the previous method, such as systemwide package tracking and upgrades (either by the system package manager or the user manually remembering to do it!), reduction of fragmentation, etc.; and it is more work to maintain.
3. Don't bother with your library at all; just reimplement whatever they want themselves (in a poorer fashion).
It's hard to quantify how much this happens, but in my experience, C++ projects do seem to have a bias toward building up little piles of basic utilities rather than reaching for a library. At the other extreme would be node.js and NPM - this post, as well as a Debian thread from a few months ago it belongs to, containing much handwringing about how to fit it into their system, is a good read:
https://lists.debian.org/debian-devel/2015/08/msg00603.html
(Spoiler: It's the build dependency graph for building jQuery, which contains some 491 entries, although it lists packages multiple times when they are referenced by multiple dependencies.)
Some NPM packages are literally 5 lines of code. Arguably still better than copy and paste... maybe...
I don't think C/C++ need to go there; most languages with package managers don't. But it's a good example of how the presence of packaging tools, as internalized into a programming language's culture, significantly changes the way people write code in those languages. And I think C/C++ could be a lot more pleasant if it were easier to reach for utilities outside of the standard library. (Especially pure C, which lacks an equivalent of the STL in its standard library - while the language may prevent writing data structures as neatly as in C++, you can still express some generalized high level structures pretty well and efficiently; and I think the standard library is partly to blame for the fact that people usually don't, instead building half-assed special-purpose data structure implementations every time one is required.)
...
I know, the idea of having a different package manager for every language sounds awful. It is awful, both for the user who needs to remember how each one works, and for the developer who's screwed if they want to depend on something written in a different language. I'd be quite interested in the idea of building something that feels like a language package manager, but is actually just Nix or something with some useful defaults...
But I'm starting to be convinced that having nothing at all is worse.
You allude to the complexity of C builds. While real, a huge fraction of this is not caused by any inherent difference between C and interpreted languages, but simply the diversity and general mess of C build systems. (Of course, some low level programs really do require complex build processes, and those programs are more likely to be written in C than Ruby, but those are the minority.)
And this is something a package manager can significantly, simply by providing less flexibility and therefore more standardization. Ideally, if you can build one package from the package manager, you can build 'em all.
Somewhat belated disclaimer: I haven't given conan.io more than a quick look, so I don't know how well it actually solves any of the preceding, heh. But I've wanted to see a good C package manager for a while, and I fully intend to check this one out when I have the chance.