I totally agree - I’m always excited to find header-only C libraries, even if I have no use for them at the moment. The idea that I can just drop in a .h file with little to no maintenance is quite appealing. I don’t have to worry about finding the right package, linking against the right version of a .so or building a static version of the entire source if I want to build a static binary. And of course there’s less dependency insanity - I hate deep dependency trees.
I understand the sentiment, and there is definitely value in minimizing dependencies and quirks. Drop-in libraries seem like they would also definitely be at the library end of the framework-library spectrum, something that doesn’t get enough praise, and which definitely makes code reuse easier.
At the same time, trouble with build systems and dependencies is mostly something that affects Windows development and embedded development.
If there is a -dev package in a distribution, really, who cares about what hoops the distro people had to jump through to get it in there*? If it has pkg-config support, you’re good to go, and as for C++ interoperability: you’ll be using the distro default compiler, just like the package used.
The main problem here is the lack of a default package repo and dependency management for C++, but in a distro, that’s the distro’s dependency management and meta build system.
I don’t mean you need to get your thing included in some distro’s official repo, just that building your own thing the same way as a distro package resolves a lot of this trouble.
* There is definitely an argument for knowing what your code and its dependencies does, but that’s not the focus of the article.
I include all 3rd party libraries I use in my repo (at work we vendor the build system too) because I don’t want to get bit by:
Porting to Windows, as you said
Porting to OSX
(Porting to OpenBSD)
(Cross compiling)
Someone I work with switching to a distro that doesn’t have pkg-config support for the library
Someone I work with switching to a distro that packages the wrong version of the library
The distro maintainers updating the package with breaking changes
The distro maintainers updating the package which shouldn’t have breaking changes but they screwed it up (this happens fairly often w/ archlinux these days)
Not being able to patch the libraries I use
I ship binaries on Linux, so I’d also have to worry about my users using distros that don’t package the library/package the wrong version/package the right version but screw it up somehow.
All of this goes away when you put the source code in your repo and static link against it. For the libraries you can’t ship (X related things and ALSA) you use dlopen, so when it fails you can at least log something useful.
Back when I used to spend my free cycles working on game development and adjacent activities, the simplicity of having some .lib and .h files and adding them to the build system was so nice. Double the work for debug libs, sure, but overall it was just super painless (at least on Windows and Visual Studio). On Linux, though, it could get gnarly quickly until we shipped fixed assets.
And now, in web land…oy vey, this package management nonsense in pretty much everything just makes me sad and missing the old days.
Another very useful property is low churn, almost always by having a low bug rate. Churn is when a library’s changes require changes in your own code for little or no increase in value to the project. There are a few common ways to achieve low bug rates: tightly limited scope, age, robust testing, small interface, etc. But the less a dependency needs to be updated for a bugfix, the less likely it creates churn when a bug requires an update that includes unneccesary changes.
On the flipmode, you’d better hope they don’t have serious or security-related bugs, because now you have to update the whole package to update a library.
I totally agree - I’m always excited to find header-only C libraries, even if I have no use for them at the moment. The idea that I can just drop in a
.hfile with little to no maintenance is quite appealing. I don’t have to worry about finding the right package, linking against the right version of a.soor building a static version of the entire source if I want to build a static binary. And of course there’s less dependency insanity - I hate deep dependency trees.I understand the sentiment, and there is definitely value in minimizing dependencies and quirks. Drop-in libraries seem like they would also definitely be at the library end of the framework-library spectrum, something that doesn’t get enough praise, and which definitely makes code reuse easier.
At the same time, trouble with build systems and dependencies is mostly something that affects Windows development and embedded development.
If there is a -dev package in a distribution, really, who cares about what hoops the distro people had to jump through to get it in there*? If it has pkg-config support, you’re good to go, and as for C++ interoperability: you’ll be using the distro default compiler, just like the package used.
The main problem here is the lack of a default package repo and dependency management for C++, but in a distro, that’s the distro’s dependency management and meta build system.
I don’t mean you need to get your thing included in some distro’s official repo, just that building your own thing the same way as a distro package resolves a lot of this trouble.
* There is definitely an argument for knowing what your code and its dependencies does, but that’s not the focus of the article.
I include all 3rd party libraries I use in my repo (at work we vendor the build system too) because I don’t want to get bit by:
I ship binaries on Linux, so I’d also have to worry about my users using distros that don’t package the library/package the wrong version/package the right version but screw it up somehow.
All of this goes away when you put the source code in your repo and static link against it. For the libraries you can’t ship (X related things and ALSA) you use
dlopen, so when it fails you can at least log something useful.Back when I used to spend my free cycles working on game development and adjacent activities, the simplicity of having some
.liband.hfiles and adding them to the build system was so nice. Double the work for debug libs, sure, but overall it was just super painless (at least on Windows and Visual Studio). On Linux, though, it could get gnarly quickly until we shipped fixed assets.And now, in web land…oy vey, this package management nonsense in pretty much everything just makes me sad and missing the old days.
Another very useful property is low churn, almost always by having a low bug rate. Churn is when a library’s changes require changes in your own code for little or no increase in value to the project. There are a few common ways to achieve low bug rates: tightly limited scope, age, robust testing, small interface, etc. But the less a dependency needs to be updated for a bugfix, the less likely it creates churn when a bug requires an update that includes unneccesary changes.
On the flipmode, you’d better hope they don’t have serious or security-related bugs, because now you have to update the whole package to update a library.