Putting external library source files directly into my project does not sound sane at all, and it is definitely not the only option for static libs on Windows. You can also make the library project a component of your solution, and add a reference to it in dependent project(s). That way, they have proper separation but are all built from source.
Having now read the rationale for single header libraries, I am completely unconvinced. These people either don't know how their tools work, or are making bad choices to coddle people who don't. Even forgetting the wasted time parsing the #ifdef'ed out implementation section over and over, it screws up separate compilation. Every time you tweak the implementation section, all the files that #include it will recompile for no good reason.
I was convinced of the header-only approach when I replaced DevIL, libpng and libjpeg (all of them made of a myriad of source files and build options, not to mention using non-portable build systems that don't really work out of the box on Windows) with 3 stb headers: stb_image.h, stb_image_resize.h and stb_image_write.h
Even if the compile time is affected (which I never noticed) this is only a minor inconvenience compared to the wins those 3 header files provide.
It's not either "build-system dependent mess" or "everything in header." The alternative to "everything in header" is "header file has interface, .c file has implementation." Then you add the .c file to your project, include the .h file, and it works better than "everything in .h" since instead of 20,000 lines all other .c files in user projects have to see only a few hundred lines, which compiles faster. And that's how C projects were supposed to be organized since the beginnings. You don't have to have dynamically bound files if that isn't needed. Some licenses insist on dynamical linking, but when you make your library, your decisions on how it's linked are independent of your decision to stuff the implementation in .h.
I agree that libpng and friends are an abomination, but a reaction all the way back to a single header file is taking it too far. There is a healthier middle ground that doesn't go against the grain of decades of tooling. Wouldn't a streamlined interface and fewer build options be sufficient? It's not like compiling multiple source files is hard.
You're probably not going to be tweaking the implementation section.
I prefer the 2-file approach myself, but the basic idea of distributing source files that the user adds into their own project is a good one. I much prefer it to having a solutionful of random projects, each of which inevitably needs its settings carefully tweaking to make sure everything works properly. Though I do admit that is not a very high bar.
831 commits in this repository tells me it is tweaked regularly. I guess the next response is: you probably aren't going to be updating your copy. That, and the idea that a project full of random source files is better than a structured solution of component projects, tells me where people's heads are at. We're not going to agree on this!
Having now read the rationale for single header libraries, I am completely unconvinced. These people either don't know how their tools work, or are making bad choices to coddle people who don't. Even forgetting the wasted time parsing the #ifdef'ed out implementation section over and over, it screws up separate compilation. Every time you tweak the implementation section, all the files that #include it will recompile for no good reason.