It's very hard to avoid turing completeness, and it's normally not particularly valuable to avoid it unless you have some extremely strong requirement for forma

It's very hard to avoid turing completeness, and it's normally not particularly valuable to avoid it unless you have some extremely strong requirement for formal reasoning about your code. I've not found that difficulty of understanding correlates well with turing completeness in practice (see regular expressions for an example of a non-turing complete system which are famously difficult to understand). And in the case of a build system specifically, generally if you don't give some generally programmable interface to it then another wrapper layer will appear over it which does. Decisions in build systems are often enough complex enough to warrant a configuration language capable of expressing many different things. (This doesn't necessarily need to be an integral part of the build system: for example rust's package manager/build system, cargo, has a fairly simple non-turing complete configuration file but can run a build.rs program which can through a simple protocol of printing out values adjust many of the decisions cargo makes). In fact, I'd say that CMake suffers most from not embracing that from the start. It's scripting language has clearly grown organically in a messy fashion from a configuration language, instead of being designed from the start with scripting in mind (at which point it may have just been a better idea to use an existing language, like lua, tcl, or python).