I take it so that zig build system is Turing complete, isn't it?
There is a reason why, for example, meson build system DSL is made to be non-Turing complete. It makes reasoning much simpler.
IME you really need a programming language to describe a build, even when it is desired that the result looks 'mostly declarative' in the end.
E.g. not sure how Meson handles this, but when I have a project with dozens of similar build targets and platform specific compile options, I really want to do the build description in a loop instead of a data tree.
PS: apparently Meson build scripts can also have variables, conditions and loops, which I guess makes the difference to an actually Turing complete build system rather esoterical?
A proper build system is so much more than just describing build targets and their dependencies, you also want to generate source code, copy and process data files, communicate with REST services etc... The more this happens in a 'real' programming language the better.
I fell in love with the ninja build system recently. It's machine language for build systems, and I can write my own scripts to generate the ninja build file, rather than introducing any new language from someone else just for build descriptions.
Meson has the ability to generate code and process data files. Why do you need to communicate with REST? Meson support that however by allowing you to break out using the `run_command()` function.
Uploading build output somewhere for instance. However this may overlap with CI tasks (but there, usually YAML is used to run shell commands, which is also a bit of a crutch).
That's just your opinion though ;) Why should the process of producing a build artifact be different from putting the artifact into the right place? E.g. Makefiles usually have a 'make install' step which isn't all that different from uploading the build result somewhere, and make definitely counts as a build system.
I'm creating a different build system (not Zig's), and I'm taking a different approach. Instead of a non-Turing-complete language, I've made one that is as powerful as possible. However, it will allow users to restrict the language so that they will only use subsets, and those subsets will not necessarily be Turing-complete.
In this way, it has the power to do anything, but the ability to restrict that power for ease-of-use.
When it comes to reasoning ability, Turing-completeness is a red herring. Turing-completeness falls beyond the reasoning ability of something that has unbounded computational power and unbounded patience, but because people only have access to bounded computational power and have bounded patience, their limit of feasible reasoning are well below Turing-completeness.
A language with nothing but boolean variables and functions with no recursion, or a language with nothing but boolean variables and loops of up to a depth of 2 can already encode TQBF [1], which makes reasoning about it intractable (it's PSPACE-complete). Because most build systems fall within that category they might as well be Turing complete.
