As absurd as it sounds, perhaps the simplest way to manage the dependencies of your C projects is to install the library package offered by your distribution.
The C programming language predates the time when using third party libraries was common.
When it became commonplace to depend on third party or system libraries, because of the special status C enjoys in the software infrastructure, OS and distro developers bend over backwards to accomodate C linkage, providing pre-packaged dynamic linking objects.
The status quo is actually rather unfortunate. Several package management tools exist to attempt to address the issue, but there is no de-facto standard and every project makes its own choice.
> The C programming language predates the time when using third party libraries was common.
The English language predates spaceflight, but has adapted. PHP predates proper security practices, but has adapted. Javascript predates the Document Object Model but has adapted.
For that matter, Javascript also predates the time when using third party libraries was common.
Yet language still takes time to adapt. Formally, it takes years for words to enter the dictionary. Informally, it takes time for new vocabulary to spread. For example, in the early days of computers, it was very common for terminology to be used incorrectly.
Of course, there is more going on with C than the use of new "words" introduced through libraries. Even though it is viewed as a portable language, most of that portability is between hardware architectures and operating systems of the same class. Almost everything above that is handled by vendor specific libraries so there was likely less of a drive to standardize on library management. This has negative consequences in today's environment, but it would have taken foresight to predict that outcome.
In a manner of speaking (and historically), yes. Code that people write in C is often low-level enough so that it only requires the standard library and the OS API.
Yes, what you see in JS is totally insane compared to what people used to do in c and c++.
And you just install packages from your linux distro repository. If you want to distribute your own code, rhen you make a package out of it and that will handle your dependancies for you.
I disagree with this. There is no C equivalent to the C++ STL included as part of any OS distribution, which means that any C code needing something as basic as a hashtable has to rely on a nonstandard third party library.
Well C packages are usually just libraries you install with a distro's package manager. Distros (distributions, e.g. Linux distributions) are mainly an effort to integrate many programs and libraries into a usable complete OS, the package manager of a distro is solving the purpose of a "package manager" that would often be designed for a specific language but for C programs as well as C++, or anything else they wanted a package for in their distro.
A lot of questions arise:
1) How do you do deployments? e.g in Node/Ruby/Python u can simply have a package.json (or Gemfile) with all the dependencies.
2) How do you dependencies? Let's say I am building a new C library that depends on 5 other dependencies, how do I let users know?
> How do you dependencies? Let's say I am building a new C library that depends on 5 other dependencies, how do I let users know?
Via a Dockerfile? ;)
But seriously, this is typically done in the INSTALL.txt installation instruction file for your library, and it’s up to the user to make sure any dependencies are properly installed and configured.
For dependencies that aren’t commonly installed, tools will often include their source and build them from scratch.
It’s a misnomer to say C package management is broken, because it doesn’t have any.
1. The same way you deploy Ruby/python to your system? They are written in C and most teams have no issue getting those deployed. If your answer is that you are deploying Ruby and python using the system package manager; then the answer here is that you deploy your dependencies for your C code using your package manager.
2. cmake and autoconf will both let you list dependencies and provide error messages to tell users to install them. It won't auto-install dependencies like a package.json or tell a user where to get the dependencies, but the message that something needs to be installed can be passed to the user.
For executables: actual real statically linked binary. You have a single executable containing all the dependencies and all necessary runtime support.
For libraries: no standard mechanism. On Linux, you can generally make a "libfoo" package that specifies the dependencies. On Windows, this is a bit more of a problem, but people can and do just hand out a DLL.
Or you make people build the dependencies from source as well.
(As an old school C developer, I see containers as occupying the same conceptual space as statically linked binaries for distribution. It's just that very few other languages will let you make a true standalone executable.)
You can do deployments with dependencies by building a distribution package of your own software, using the distribution's packaging tools. The tools do work quite well. The real problem is that this only works reliably for a single OS distribution. To support another Linux distribution, you need to redo the packaging. Even distributions that use the same package format (such as rpm or deb) are not quite compatible, since the names and versions of the dependencies vary.
I just make a PKGBUILD file for my project. Lets me specify dependencies, build and install instructions, anything it needs. Then I can build the package and install it on any Arch Linux system.
That sounds like a distro.