> But with .c files, when you have multiplatform project, you need to put it in other "3rd party" tools.

No you don't: just act as if you've written the damn thing yourself. Your tools don't have to know. How being multiplatform changes anything?

It changes everything. Each platform brings its own preferred build system with it, which needs a copy of a definitive and explicit lost of all source files to compile the project. This is cumbersome to maintain. Header files on the other hand are licked up be the compiler automatically after seeing the include statement in the source. So this is actually much less time consuming to maintain.

Also, it shows that building C and C++ is a sad affair.

Why you need to do that with .c files? You can just drop the .c/.h pair into the same place as you would put the single .h file and the rest of your C/C++ files and use it like that.

Let's say you need zip lib functionality in your project. If it will be available as set of .h files you would include it by one line `#include zip.h` in your .c file.

But libzip is made of .c files. How you would include it in your multiplatform project ? Visual Studio, XCode, etc...

In general it would be great if C has `#include source "some.c"` feature.

So you would add single file zip-lib.c that will contain `#include source ...` references to all needed .c files.

But C/C++ has no modules as other languages so we need palliatives like make files, etc.

I am not comparing many-c-files (like your libzip example) with single header, i am comparing the single header with a pair of c/h files.

Easy, one links to the binary library.

It really feels strange that young devs find it so hard to use a linker.

It feels strange that you're unfamiliar with the headaches that brings for cross platform projects.

Those headers have code that most likely require linking with other libraries, many of each are not available in source code that one can dump into an header file.

So it appears like a little convenience just for not having to deal with installing binary libraries, at the expense of wasting everyone's time.

The time I waste installing a binary library?

Once per platform for the longevity of the project.

The time I waste building software with header only library?

Every single time I do make all.

Dealing with pre-compiled libs in the Visual Studio ecosystem is more complicated that you make it sound like.

For a start there are 4 incompatible standard libraries (dll vs static, debug vs optimized) and that's already a big headache. Also to a mix, a bunch of Visual Studio versions with enough difference to make it frequent that one compiled for e.g. 2010 doesn't work with 2015 or vice-versa.

To me the nature of those small libraries (regardless of the number of source files) is that they are highly portable and designed to always be compiled from source code to prevent those issues.

The point of single-file header libraries is that generally they are relatively small, and do not rely on linking with other libraries (outside the C runtime).

That might be the point, but it doesn't mirror many use cases.

You are free to split it into .h and .c if you want, every single header library I have used has an IMPLEMENTATION block to make doing so very simple.