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.
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.
(for example: https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029b...)
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?
https://mesonbuild.com/Syntax.html#logical-operations
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.
Is ninja not expressive enough for your needs?
But then some things become impossible to do.
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.
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.
[1]: https://en.wikipedia.org/wiki/True_quantified_Boolean_formul...