4 ms·

From my point of view waf is just a different set of magic that happens to be hosted inside a python VM. Now, admittedly, it looks like a rather nice set of ma

by mst 5y ago

From my point of view waf is just a different set of magic that happens to be hosted inside a python VM. Now, admittedly, it looks like a rather nice set of magic and I'm glad you've mentioned it but 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. Honestly the main problem with external DSLs for this sort of work is the authors tend to underestimate how much programmability they'll need so the language ends up a bit pants, but waf is still a DSL just like chef is a DSL so your specific criticism seems a bit misplaced. Also, "not being Turing complete" can absolutely have its advantages - depends on your environment and your team. (and now I'm going to read more waf docs ;)

bogwog 5y ago
> 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)
slavik81 5y ago
It was admittedly a decade ago at this point, but I used waf before I used CMake. The thing about CMake is that it has an ugly language, but a fairly simple model of the compilation process. The first week I started using CMake, I set up a project that built a program, then used that program to generate some code from an input file, then compiled that code as part of a library, then included that library as part of a larger application. I'd previously spent much longer trying to get that working in waf. I just couldn't figure out how to properly define dependency relationships for anything besides the built-in languages. It looked like it would be simple, but I could never get it to actually work (correctly handling incremental builds and parallel compilation). Waf has probably improved significantly since I last tried it, but the point of this story is that I agree with you. Learning a build system is more than just learning a language. You have to learn a data model and the functions that manipulate it. In my case, that was more difficult than learning a crufty macro language.

by mst 5y ago

bogwog 5y ago

> 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)

slavik81 5y ago

It was admittedly a decade ago at this point, but I used waf before I used CMake. The thing about CMake is that it has an ugly language, but a fairly simple model of the compilation process. The first week I started using CMake, I set up a project that built a program, then used that program to generate some code from an input file, then compiled that code as part of a library, then included that library as part of a larger application. I'd previously spent much longer trying to get that working in waf. I just couldn't figure out how to properly define dependency relationships for anything besides the built-in languages. It looked like it would be simple, but I could never get it to actually work (correctly handling incremental builds and parallel compilation). Waf has probably improved significantly since I last tried it, but the point of this story is that I agree with you. Learning a build system is more than just learning a language. You have to learn a data model and the functions that manipulate it. In my case, that was more difficult than learning a crufty macro language.