Do I just download the header files and use it that way, or is there a package manager for this?
In that case do I manage updates by removing the old header file and download the new version?
Do I just download the header files and use it that way, or is there a package manager for this?
In that case do I manage updates by removing the old header file and download the new version?
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.
1. apt-get install libsodium libsodium-dev
2. #include "sodium.h" where needed
3. Add -lsodium flag to gcc/clang linking command
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.
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.
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.
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?
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(Not razzing you or anything; I just genuinely found that question startling, having started programming in the 1990s.)