It also automatically enables "global optimisation" in most cases.

This style is called "amalgamation" and SQLite is distributed (but not developed) in this way.

Does this impose limitations on the code? I think all functions, even private, should be "namespaced" (i.e. in C - prefixed) then? Kind of awkward, but otherwise amalgamation is a great idea.

C doesn't have "private" functions in that way, what it has is "static" functions, and this is indeed the biggest limitation of doing this kind of amalgamated build.

If you mark a function as static, it means that has internal linkage and is only visible inside the translation unit was defined and no symbol is exported for linking. This is not the default: if you just define a function with some name, that symbol is in general visible to all other translation units that gets linked together by the linker (though with no type information attached, just the name of the symbol. Making sure the type information is correct is the purpose of header files).

That means you can have any number of functions marked static in different translation units with the same name, and it's fine, they don't see each other. If you're doing an amalgamated build like this, that no longer works: all symbols have to have globally unique names.

In addition, of course, you don't get the "separation" that "static" provides. You can't call a static function across a translation unit boundary, but since this just one big translation unit, anything goes: all functions can call all other functions, even if they shouldn't.

> Does this impose limitations on the code?

It does. Any technique that relies on features specific to translation units, such as taking advantage of internal linkage to reuse symbols to hold data specific to translation units, cannot be used anymore.

Also, even though global builds are faster, you forego the ability to do incremental builds which makes working over a bug a more time-consuming task.

TIL it has a name. Doing what sqlite does gives you the best of both traditional and single header projects I imagine.

> This style is called "amalgamation" and SQLite is distributed (but not developed) in this way.

These are actually called "unity builds" or "jumbo builds", and some build systems such as CMake offer support for this.

https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.htm...

Afaik this is exactly what Unity builds are. https://en.wikipedia.org/wiki/Unity_build

Yeah. Though most projects still use header files with unity builds, so I decided not to call them that. It wasn't the concept of a unity build that I was emphasising, it was the idea of not forward-declaring everything.

> Yeah. Though most projects still use header files with unity builds, so I decided not to call them that.

There is nothing inherently special in header files. They are just a convention where you use a specific extension in source files you mostly use to pass declarations. Nothing stops you from using the .c extension on all files, and there is nothing special in passing declarations in one place and definitions in another place.

Of course! But, saying 'unity build' puts emphasis on the fact that you compile all the C files 'in unity', in a single CU. What _I_ wanted to put emphasis on is that you can skip the header files, and that coincidentally means you also have to unity build.

The fact that most unity built projects still use headers made me hesitant to use the term, as that would put emphasis on building a single CU, as opposed to not forward declaring in headers.

Build systems like Meson can even enable/disable this with an option ootb.

For smaller C++ projects this tends to be way faster than the conventional wisdom of having many CUs, mostly because all the library bloat will only be parsed and instantiated once.

Also reduces link time.

I find that projects up to around 50K lines compiles instantly as a single file/"unity build" and is my preferred way for most of my projects.

> Also reduces link time.

It's important to stress that it does more than reduce link time: unity builds completely eliminate linking when plugging together submodules, and the final project linking simply has far fewer object files to link.

This really should be solved at the compiler level, rather than forcing people to restructure their projects.

I never really had a good grasp of C. Why is this code novel? It looks like importing a function in any language.

It's including another C file, normally you'd just include a "header file" in C and compile each C file separately.

For those who don't use C: header files are more or less an interface description and (usually) don't include any code. The code is added from external objects during the second "linking" step.

Oh, I see: including a header file injects forward declarations into the calling file. Each c file gets compiled separately into object code unless you directly import them like the code above is doing. In that case it essentially dumps the full text of the file into the calling file, which causes serial compilation of a single object file.

Unless I'm mistaken that clears some stuff up for me. Thank you!

That's my understanding as well, so I think you are correct but I am no C wizard myself :)

> I never really had a good grasp of C. Why is this code novel? It looks like importing a function in any language.

Unity builds are a very old and widely established concept. I dare to speculate they are older than the regular header and source file split, as C required a full blown preprocessor to split code in separate files and also someone had to come up with the include guard trick to get around the limitations of including the same definition multiple times.

They aren't employed that often because there are some tradeoffs and in large projects it's benefitial to split them in smaller translation units to limit the scope of incremental builds.