Someone more experienced at C can jump in and correct me but from my understanding you're correct, you download the files. You could use git to create subrepos for dependencies in a directory in your project, too. When I've asked this question before those were the answers I got.

I saw a project called conan.io, looked interesting. I know Microsoft created vcpkg.io aswell.

I’m too used to Ruby and how gems are installed, I think I’m looking for a similar experience in C where you find the lib you want, install it and include it in your code.

Yeah I looked at conan and you can specify git projects to install which is nice. I expect vcpkg to be great for a Windows / Visual Studio setup but I'm on Mac/Linux so haven't really looked. Even with Conan I've not found something as nice as gems/pip/npm for ease of use and it's one of the reasons I end up looking at Rust - because cargo is so familiar to me from a Python background.

Edit: I saw a project recently written in C++ and they had subrepos in a `deps/` directory and then linked to those, so it was all manually managed. If I were to make a new project in C++ I think that's how I'd go too.

This reminds me of the time a younger coworker asked me if there's a way to run a diff without putting the files in a git repo first. Some questions never even occur to us geezers to ask...

(Not razzing you or anything; I just genuinely found that question startling, having started programming in the 1990s.)

That’s interesting

I use Nix as a package manager for my C projects. It works very well and has out of the box support for most C build systems (make, autotools, cmake, meson)

Really? You manage the libraries through nix?

Yes!

just pop in a:

  stdenv.mkDerivation {
    pname = "myproject";
    version = "0.0.0";
    nativeBuildInputs = [ pkg-config ninja meson ];
    buildInputs = [ openssl zlib libfido2 ];
  }

in a default.nix, type `nix-shell`. and you'll have meson, ninja, and all your libraries! All ready to go

Generally you would use the operating system's package manager to install both the headers and the library. On distributions like Debian the library would be in a package called `libsodium` and the headers in `libsodium-dev`.

Once the files are on the system, you use command-line switches to tell the compiler where to look for headers and which libraries to link to. Libraries are often loaded dynamically when the binary is started, so they are not actually included in the file.

Because maintaining the correct switches is a bit of a pain, there are tools like `pkg-config` to generate them for you. And there are tools like `autoconf` and `automake` to generate build scripts to orchestrate those tools.

In libraries it's pretty common for APIs to a library to be fairly stable, so the function signatures generally don't change very much in the headers. This is also why your application can be dynamically linked to different versions of a library.

There are obviously limitations and that's when people come into the equation. For example, OS distribution maintainers juggle these dependencies for you.

For package-manager-installed libraries in mainstream distros, you usually don't have to worry about the -I or -L flags, or deal with pkg-config, since the libraries are installed in places that are already under the compiler's default search paths. So the steps can be reduced to:

1. apt-get install libsodium libsodium-dev

2. #include "sodium.h" where needed

3. Add -lsodium flag to gcc/clang linking command

For C/C++ projects that use meson as the build system, there is an excellent way to manage (some, supported) dependencies:

https://mesonbuild.com/Wrapdb-projects.html

https://mesonbuild.com/Wrap-dependency-system-manual.html

meson will download and build the libraries automatically and give you a variable which you pass as a regular dependency into the built target:

https://github.com/qemu/qemu/tree/005ad32358f12fe9313a4a0191...

https://github.com/harfbuzz/harfbuzz/tree/main/subprojects

https://github.com/harfbuzz/harfbuzz/blob/37457412b3212463c5...

Or, if you're using proper operating systems, they're managed by the usual package manager, just like everything else.

It depends.

Some "single-file" libraries only have the one header, so you can use that one file. Though they often require a bit of trickery to be compiled correctly, so I prefer those with two file, one .h header and one .c source.

Some libraries are popular enough that they’re distributed in your package manager of choice: whatever your Linux/BSD distribution uses, Nix, a Cargo-like repository in some cases… In this case you can download that package and depend on it.

All working libraries can be built from source, one way or another. They each have their own preferred build system though. Most can be installed from source, so you don’t need to be aware of their build system to use it. But if you take on the dependency like that now your users will depend on the library so it’s not exactly free.

Some libraries offer several or all of the above.

Managing updates depend on how you integrate the library. If you use it as a system dependency, your users need to download and update the correct version themselves. Package managers can help there (use Ubuntu/Nix/Ports, get security updates for free… if you trust them to be quick enough, which they will be if the library is popular). The alternative is to ship your own copy of the library yourself, either by building it at home with their build system and manually importing headers & .so/.dll, or absorb their source code into your own build system (you’re on your own but you have full control).

Which is best is… up to who you’re speaking to. To oversimplify the issue, I’d say distro maintainers don’t trust developers to deliver security updates in time, so they want everyone to use .so and dynamic linking everywhere so security updates can happen in a timely manner. On the other hand developers don’t trust distro maintainers to do regular updates in a timely manner, so they’re stuck to old versions of their favourite libraries. Those who do both… maybe have gone insane from the cognitive dissonance?