[JonChesterfield]

Agreed. Essentially the build system should do whatever crackpot things it likes to bootstrap with bespoke languages and so forth, but the output should be a single somewhat auditable C file that gets fed to a compiler, not a binary with exciting dependencies on wherever it was built.

How sqlite constructs the single source/header pair looks ideal. Various efforts have bundled lua and some libraries into a single C file too.

Check in that generated C file and you have trivial 'bootstrap' for everyone else. Ideally have some CI that checks the dev files still generate that exact C file on request.

[Rochus]

Lua is even simpler; there is an all.c which simply includes all other c files in a decent order, so you can just type "GCC all.c" resulting in a full Lua vm executable on all platforms. Other projects like e.g. Duktape offer amalgamated c files as you seem to suggest, but these are redundant.

[JonChesterfield]

This sounded wrong so I checked. You're correct. Current GitHub has a file onelua.c from three years ago.

Turns out I forked the project four years ago. Slightly different implementation in that I expanded the #includes to get a single file I can copy around and hacked in a few libraries (libuv, lfs and penlight iirc). Not totally pleased to discover that was so long ago.

Great to see that cc onelua.c gets the job done today.

[Rochus]

A file called all.c is also present in Lua 5.1 from 2006 in the etc subdirectory.

[JonChesterfield]

Could be? https://github.com/lua/lua doesn't seem to have an /etc subdirectory and I think that's where I cloned from. Can totally believe the work had already been done by someone else and I failed to find it.

[Rochus]

I recommend to download from the official site: https://www.lua.org/versions.html or https://www.lua.org/ftp/.

[Rochus]

I just did an experiment with Lua 5.4.4; moved the file luac.c to another directory and then executed "gcc *.c -lm -o lua" in the src directory; compiled the vm without an issue, and "./lua" does what expected.

[gaurav1804]

I'm not really sure what you are pointing at here. But if you are suggesting to have a single C file that has configurations, dependencies and commands to be run while building your project, then that is not a very good idea. Simply because.... we may not even want to use gcc to build our projects.

We may want a more suitable tool that is first of all more user-friendly (like Beast), allows you flexibility in defining custom tasks (like Beast does).

Secondly, we simply may not have gcc to compile the all.c file (as mentioned in comments below). We just want a unified tool (an CLI preferably) that does all this for us. This is what Beast does. Make and Ninja are long standing build systems that prove my point.

Plus, you get Beast binary as a standalone executable. Check it out here: https://github.com/GauravDawra/Beast/releases/tag/v1.1.0

[JonChesterfield]

I mean a single beast.c that contains absolutely everything required to build a static executable beast which is your build tool. Ideally in C that multiple compilers can deal with. Building that source during dev and checking it in makes bootstrap trivial for users.