Yeah, definitely debatable. IME the difference between a single STB-style header and a single .h/.c pair isn't really all that relevant in practice (not enough to waste much time discussing the pros and cons at least - especially the build time consequences are usually overblown, I benchmarked my own header libraries and it comes down to a couple of seconds at most for including the header in thousands of C source files - with the implementation skipped of course).
The actual problem are libraries with hundreds or thousands of source files in dozens of directories and a CMakeLists.txt file from hell.
A good C/C++ library should be easy to drop into a project, trivial to integrate with any build system (or no build system at all), and no need for a package manager. If configuration is necessary it should happen with a small number of defines.
...one arguable advantage of STB-style headers is that you can include all header-library implementations of a project in a single source file, which might actually speed up overall build time because this benefits from the same advantages as unity/jumbo builds (especially in case of C++ code when stdlib headers need to be included). But for C code - where the stdlib headers are just a couple of hundred lines of simple declarations instead of tens-of-thousands of lines of gnarly template code - the difference is also negligible.
PS: another advantage of STB-style headers is that you can build even non-trivial projects into a single source file and compile that with `cc main.c -o mytool`, e.g. no need for a build system at all (of course the same is possible by including .c files into the main.c file, even if that might look a bit icky).
> The actual problem are libraries with hundreds or thousands of source files in dozens of directories and a CMakeLists.txt file from hell.
Why is that a problem? If you have a large library, surely it's better to properly break it up into separate files?!
> no need for a package manager.
Well, yeah if you don't want even a build system, large projects in general become really difficult to maintain anyway. The solution seems to be like every programming language created after 1989? Have a package manager and make it irrelevant if the library contains 1 file or 1000. What's the reason C resists so much using a package manager, even when similarly low level languages like Rust and Zig have them and make them first class citizens?
> Why is that a problem? If you have a large library, surely it's better to properly break it up into separate files?!
That's at best good for developing the library (even that is debatable though), but definitely not when just using the source-distribution of the library in a project.
> What's the reason C resists so much using a package manager...
One important problem is that there are so many package managers and build systems for C and C++ projects. So the choice for a library author is either to support all package managers and build systems (not really a realistic option), or none specifically (much better but requires that the library source distribution is designed for simple integration into projects without esoteric build requirements).
Requiring a specific package manager and build system is hostile to users preferring other tools.
The problem doesn't lie with C or C++ users, but with the respective language committees saying "dependency management and build system standardization isn't our problem".
> If you have a large library, surely it's better to properly break it up into separate files?!
Sqlite solves this dilemma by providing both: regular source code repository with separate files for development and an "amalgamation" with everything in a single .c file. The latter makes it really easy to integrate.
The actual problem are libraries with hundreds or thousands of source files in dozens of directories and a CMakeLists.txt file from hell.
A good C/C++ library should be easy to drop into a project, trivial to integrate with any build system (or no build system at all), and no need for a package manager. If configuration is necessary it should happen with a small number of defines.
...one arguable advantage of STB-style headers is that you can include all header-library implementations of a project in a single source file, which might actually speed up overall build time because this benefits from the same advantages as unity/jumbo builds (especially in case of C++ code when stdlib headers need to be included). But for C code - where the stdlib headers are just a couple of hundred lines of simple declarations instead of tens-of-thousands of lines of gnarly template code - the difference is also negligible.
PS: another advantage of STB-style headers is that you can build even non-trivial projects into a single source file and compile that with `cc main.c -o mytool`, e.g. no need for a build system at all (of course the same is possible by including .c files into the main.c file, even if that might look a bit icky).