> the execution is still inside the tool, not in the user provided code, so it's still a DSL, just an internal rather than external one. That seems like a weir

> the execution is still inside the tool, not in the user provided code, so it's still a DSL, just an internal rather than external one. That seems like a weird way to frame it. Waf is just a python API bundled with a command line interface, all packaged as a self-extracting zip file of python scripts. The code that runs is the code that you write using that API. Calling that magic would be a stretch I think because its pretty hard to use an API if you dont know how it works. Plus, the Waf core is tiny and always in your source tree. I guess one could argue that all APIs are DSLs, but I think thats a stretch. > Also, "not being Turing complete" can absolutely have its advantages - depends on your environment and your team. This is true, and a very relevant example of that is when the Amazon Lumberyard team switched from waf to CMake a few months back. Their waf(fork)-based build system was an unholy mess inherited from Crytek, and a common pain point for end users who just wanted to compile their games. Not sure if CMake will help them maintain discipline among the build team, but it certainly will make the project more friendly to their external customers. > and now I'm going to read more waf docs RIP your sanity. The waf docs are written for people who already know waf. The only way to really learn it is to dig through the source. I became the unfortunate victim of Lumberyard’s build system a few years ago and that was what drove me to learn it (I dont like to lose to software). Luckily, I ended up loving it. So unless you have extra motivation and/or time, I wouldnt recommend it (even though I love it)