There's quite a bit of build management going on with sqlite. Apart from that script, Dr. Hipp wrote his own source code management system[1] to fit his need and if I'm not mistaken they don't write headers by hand[2].

[1]: https://www.fossil-scm.org/

[2]: https://www.hwaci.com/sw/mkhdr/

Fossil intrigues me every time I see it mentioned. I've never found a sue for it, but it's so neat that I want to find a use for it.

The main features could be emulated with a small wrapper around git, no?

A full web ui with issue tracker is a bit more than a small wrapper.

> the actual day-to-day coding is not done in a single C file.

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.

You just don't depend on weird libraries that mess up your preprocessor state. Then you make sure that even your static (file local) variables have unique names. And then you concatenate all the header and source files.

It shouldn't be very hard, but most projects fail already at the dependency stage.

And also as a gift to optimizing compilers, from discussions I’ve had w him. The idea is that a single compilation unit (the “amalgamation”) is easy for the compiler to reason about.

Sure, but now we have -flto, somewhat negating that advantage?

Perhaps. Assumes all compilers support it, but otherwise, a testable case.

Except LTO is slow to compile and SCU is fast.

I'm not a C/C++ developer, but why can't more C/C++ projects be distributed as source amalgamations? What prevents this from happening?

As in, source to source amalgamation rather than a more complicated build system to generate a binary.

> why can't more C/C++ projects be distributed as source amalgamations

* 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".

Interesting, thank you!

Are there any ways of doing that sort of distribution header-only then, rather than single file?

For one, I think this would be cumbersome from a debugging perspective. All of the address-to-source-mappings in your DWARF section would point to things like "lib.c:237652" instead of "lib-module.c:347".

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.

There's the #line directive that can keep the original file names and line numbers.

For larger projects there is a danger of blowing out the memory on older machines when you combine everything into one monstrous C/CPP file.

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.

Is that much of a problem though? For SBCs like the Raspberry Pi you can do builds on the SBC itself. While this is neat, it is far from optimal because builds are very slow. It's much more typical for embedded systems to do you build on a host PC with a cross-compiler.

Sometimes getting that cross compiler environment set up properly, especially with all of the dependencies and build tools, is more hassle than just letting the build run overnight on the SBC itself. Especially when it has a configure script that wants to check on various properties of the target architecture as part of the build.

I'm not sure anyone thought that it was made that way, this is very explicitly for distribution and it works very well.

In a vacuum, reading that statement, that was the assumption I made. Certainly strikes me as a bit odd, but then, SQLite is a bit of an odd project. And sometimes odd projects do things differently in a way that works out well because they have the discipline to pull it off.

But it does make much more sense that it is worked on in pieces and then put back together.