>> Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mode of distribution now

I find that odd. How is that significantly better than dropping 2 files into a project and #including the header? A good build system should just compile all the C or C++ files in a given place, so nothing needs to be changed other than dropping the files in and #include where called from.

The difference will be painfully clear once you try to walk a junior developer through installing and linking new files to a large project in Visual Studio, vs "copy this .h file here and include it".

Whether or not a "good build system" should handle it, the fact that single-file libraries are much preferred these days should demonstrate most people don't have such a build system

So much of the C/C++ ecosystem revolves around knowing your build tools that, for most intents and purposes, it should honestly be considered an integral part of the languages. If I ever teach an introductory C/C++ course, I would dedicate at least 1/4 of my time to explaining:

* What a translation unit is, and how compiling a translation unit to an object file works

* What a linker is, and how the linker combines object files into a library/executable

* What make/autotools/cmake are, and how they work

* What FHS is, and how it standardizes the lib/bin/include paths that C/C++ build tools read from/install to

And so on. Any C/C++ course that goes beyond a “Hello world” program without explaining these concepts in detail does its students a disservice.

Yeah, in our class we had to figure out this mostly on our own, so after it I'm still at the level where I barely manage to make make work, I'll have to look into those other ones, thanks !

its not 'significantly better'.

but also ask "why are the tables of content prefixing the contents of all my books?"

its taken ages, but with this model, c lib authoring has finally taken something that was a core strength of pascal: single-file modularity.

though in theory there's no difference between theory and practice, in practice, there is. and this kind of packaging makes a lot of sense for a lib like this.

Why use two files instead of one?

What if you want to use the functions in other C files? What if you want to compile them all separately?

1) Include it wherever it's used. The convention is to use the preprocessor[1] so it only appears once in the final binary

2) Most developers just want to compile to a single binary. Any developer who for some reason needs separately compiled objects should be able to quickly achieve that from a single-file library

[1] https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d...

Maybe you've been living under the same rock as me. I was under a similar impression untill I decided to learn cmake last week.

I was blown away by its simplicity and power.

You can download almost any C/C++ library from GitHub then add two lines to your cmake file. It will then compile and link with your project.

Blown away.

Cmake can generate project files for Visual Studio, makefiles, and countless other formats. Better yet, you can open a cmake folder directly in Visual Studio. No need to generate a project :)

This comes as no surprise to anybody, I'm sure, but cmake is great.

It was tricky to find good information about it though. It has been around forever, but the nicer features were added recently it seems.