This is because the author of SQLite publishes it this way as a convenience to integrators; the actual day-to-day coding is not done in a single C file.
In fact, the README[1] calls out twelve "key files", and explicitly warns that SQLite "will not be the easiest library in the world to hack."
That's true - but in order for it be able to be reduced to a single C file, a lot of thought had to go into the process.
It shouldn't be very hard, but most projects fail already at the dependency stage.
As in, source to source amalgamation rather than a more complicated build system to generate a binary.
* Build time and memory increases.
* Debugger locations are less clear. MSVC debugging doesn't even work past 64KB lines.
* You still need to link it anyway when using as a library.
* Linker optimization has improved (especially clang).
* It's more difficult to modify.
SQLite has some decent reasons for it especially historically; I'm not sure those reasons are as strong for other projects.
For applications, distributing binaries is even more convenient than source code (assuming they exist for your platform).
And for libraries, "header-only" can be more of a convenience than "single-file".
Are there any ways of doing that sort of distribution header-only then, rather than single file?
It also means that you're effectively linking all you dependencies statically. In some cases this can be a plus, in some cases a minus. I think having the choice is important though.
I imagine there are lots of other parts of the toolchain that would have to be updated to support this workflow. Seems like a lot of hassle for something that, though at times complicated, mostly works.
It's already impossible to compile Firefox on a machine with 1GB of RAM because some of the files are just too big. Even with swapping enabled the build process crapped out for me last time I tried it. While 1GB machines are pretty rare these days outside of SBCs, you could easily blow out a 4GB machine if you tried to compile the whole damn thing at once, and 4GB machines are still commonly found.
But it does make much more sense that it is worked on in pieces and then put back together.