Right, but those would be your choices, it wouldn't be the library itself forcing you to do that, it would be your personal preferences. That isn't a fault of the library.
It is bloating my ABI if I'm not careful, and it makes distributing more cumbersome when it could/should be straightforward.
That's just not how you are supposed to distribute a C library, this is a poor design that clearly states "I don't know or don't care how to package my code".
TBH this is really just bikeshedding, not real issues. IMO even a tab-vs-spaces argument would have more merit as that has real practical effects (appearance of the code in tools like terminal or sites that have forced tabs like code review sites or github).
The "numbers argument" is a fallacious one.
No, "how you are supposed to distribute a C library" is not my opinion, but the experience/observations of the last 50 years of engineering. Why would we even have a .so/.a/.lib/.dll format for libraries?
As I said in a sibling comment, those are not header-only libraries. It's poorly packaged .c/.h in a single file that we happened to name with the .h extension.
It's not a header, it's a header+implementation. And it's bad practice, and any decent C developer will tell you so.
What I'm criticizing is the extra step of me having to write the .c files anyway to avoid bloating the obj files, which should have been done by the library in the first place.
https://github.com/lieff/minimp3
https://github.com/Immediate-Mode-UI/Nuklear
https://github.com/mattiasgustavsson/libs/blob/main/docs/htt...
How so? The private implementation functions are usually declared static, only the public API functions are visible to the linker. Some single-file libraries also allow to declare the entire API as static (via a config define) so that none of the library API functions are visible to the linker.