Please don't. C packaging in distros is working fine and doesn't need to turn into crap like the other language-specific package managers. If you don't know how to use pkgconf then that's your problem.
When I used to work with C many years ago, it was basically: download the headers and the binary file for your platform from the official website, place them in the header/lib paths, update the linker step in the Makefile, #include where it's needed, then use the library functions. It was a little bit more work than typing "npm install", but not so much as to cause headaches.
What do you do when the code you downloaded refers to symbols exported by libraries not already on your system? How do you figure out where those symbols should come from? What if it expects version-specific behavior and you’ve already installed a newer version of libwhatever on your system (I hope your distro package manager supports downgrades)?
These are very, very common problems; not edge cases.
Put another way: y'all know we got all these other package management/containerization/isolation systems in large part because people tried the C-library-install-by-hand/system-package-all-the-things approaches and found them severely lacking, right? CPAN was considered a godsend for a reason. NPM, for all its hilarious failings, even moreso.
> These are very, very common problems; not edge cases.
Honestly? Over the course of my career, I've only rarely encountered these sorts of problems. When I have, they've come from poorly engineered libraries anyway.
And with header only libraries (like stb) its even less than that.
I primarily write C nowadays to regain sanity from doing my day job, and the fact that there is zero bit rot and setup/fixing/middling to get things running is in stark contrast to the horrors I have to deal with professionally.
I mean … it clearly isn’t working well if problems like “what is the libssl distribution called in a given Linux distro’s package manager?” and “installing a MySQL driver in four of the five most popular programming languages in the world requires either bundling binary artifacts with language libraries or invoking a compiler toolchain in unspecified, unpredictable, and failure-prone ways” are both incredibly common and incredibly painful for many/most users and developers.
The idea of a protocol for “what artifacts in what languages does $thing depend on and how will it find them?” as discussed in the article would be incredibly powerful…IFF it were adopted widely enough to become a real standard.
Assuming that your distro is, say, Debian, then you'll know the answer to that is always libssl-dev, and if you cannot find it then there's a handy search tool (both CLI and web page: https://packages.debian.org) to help you.
I'm not very familiar with MySQL, but for C (which is what we're talking about here) I typed mysql here and it gave me a bunch of suggestions: https://packages.debian.org/search?suite=default§ion=all... Debian doesn't ship binary blobs, so I guess that's not a problem.
"I have to build something on 10 different distros" is not actually a problem that many people have.
Also, let the distros package your software. If you're not doing that, or if you're working against the distros, then you're storing up trouble.
Actually "build something on 10 different distros" is not a problem either, you just make 10 LXC containers with those distros on a $20/mo second-hand Hetzner box, sick Jenkins with trivial shell scripts on them and forget about it for a couple years or so until a need for 11th distro arrives, in which case you spend half an hour or so to set it up.
> Conan and vcpkg exist now and are actively maintained
I am not sure if it is just me, but I seem to constantly run into broken vcpkg packages with bad security patches that keep them from compiling, cmake scripts that can't find the binaries, missing headers and other fun issues.
One of my favorite blog posts. I enjoy it every time I read it. I've implemented two C package managers and they... were fine. I think it's a pretty genuinely hard thing to get right outside of a niche.
I've written two C package managers in my life. The most recent one is mildly better than the first from a decade ago, but still not quite right. If I ever build one I think is good enough I'll share, only
to mostly likely learn about 50 edge cases I didn't think of :)
Please don't. C packaging in distros is working fine and doesn't need to turn into crap like the other language-specific package managers. If you don't know how to use pkgconf then that's your problem.
When I used to work with C many years ago, it was basically: download the headers and the binary file for your platform from the official website, place them in the header/lib paths, update the linker step in the Makefile, #include where it's needed, then use the library functions. It was a little bit more work than typing "npm install", but not so much as to cause headaches.
What do you do when the code you downloaded refers to symbols exported by libraries not already on your system? How do you figure out where those symbols should come from? What if it expects version-specific behavior and you’ve already installed a newer version of libwhatever on your system (I hope your distro package manager supports downgrades)?
These are very, very common problems; not edge cases.
Put another way: y'all know we got all these other package management/containerization/isolation systems in large part because people tried the C-library-install-by-hand/system-package-all-the-things approaches and found them severely lacking, right? CPAN was considered a godsend for a reason. NPM, for all its hilarious failings, even moreso.
> These are very, very common problems; not edge cases.
Honestly? Over the course of my career, I've only rarely encountered these sorts of problems. When I have, they've come from poorly engineered libraries anyway.
And with header only libraries (like stb) its even less than that.
I primarily write C nowadays to regain sanity from doing my day job, and the fact that there is zero bit rot and setup/fixing/middling to get things running is in stark contrast to the horrors I have to deal with professionally.
I agree entirely. C doesn't need this. That I don't have to deal with such a thing has become a new and surprising advantage of the language for me.
I mean … it clearly isn’t working well if problems like “what is the libssl distribution called in a given Linux distro’s package manager?” and “installing a MySQL driver in four of the five most popular programming languages in the world requires either bundling binary artifacts with language libraries or invoking a compiler toolchain in unspecified, unpredictable, and failure-prone ways” are both incredibly common and incredibly painful for many/most users and developers.
The idea of a protocol for “what artifacts in what languages does $thing depend on and how will it find them?” as discussed in the article would be incredibly powerful…IFF it were adopted widely enough to become a real standard.
Assuming that your distro is, say, Debian, then you'll know the answer to that is always libssl-dev, and if you cannot find it then there's a handy search tool (both CLI and web page: https://packages.debian.org) to help you.
I'm not very familiar with MySQL, but for C (which is what we're talking about here) I typed mysql here and it gave me a bunch of suggestions: https://packages.debian.org/search?suite=default§ion=all... Debian doesn't ship binary blobs, so I guess that's not a problem.
"I have to build something on 10 different distros" is not actually a problem that many people have.
Also, let the distros package your software. If you're not doing that, or if you're working against the distros, then you're storing up trouble.
Actually "build something on 10 different distros" is not a problem either, you just make 10 LXC containers with those distros on a $20/mo second-hand Hetzner box, sick Jenkins with trivial shell scripts on them and forget about it for a couple years or so until a need for 11th distro arrives, in which case you spend half an hour or so to set it up.
^ This.
Plus, we already have great C package management. Its called CMake.
I hate autotools, but I have stockholm syndrome so I still use it.
Its not so hard once you learn it. Of course, you will carry that trauma with you, and rightly so. ;)
> Conan and vcpkg exist now and are actively maintained
I am not sure if it is just me, but I seem to constantly run into broken vcpkg packages with bad security patches that keep them from compiling, cmake scripts that can't find the binaries, missing headers and other fun issues.
[delayed]
C*** shaped?
very related: https://michael.orlitzky.com/articles/motherfuckers_need_pac...
One of my favorite blog posts. I enjoy it every time I read it. I've implemented two C package managers and they... were fine. I think it's a pretty genuinely hard thing to get right outside of a niche.
I've written two C package managers in my life. The most recent one is mildly better than the first from a decade ago, but still not quite right. If I ever build one I think is good enough I'll share, only to mostly likely learn about 50 edge cases I didn't think of :)