3 ms·

I like when a project I downloaded uses CMake because then I already know how to build it. Just the same old "mkdir;cd;cmake ..;build" I always do, maybe with s

by bogwog 5y ago

I like when a project I downloaded uses CMake because then I already know how to build it. Just the same old "mkdir;cd;cmake ..;build" I always do, maybe with some custom option flags. But using CMake for my own projects? Hell no. The concept of a DSL for build systems just seems awful to me. A shitty build system is one where you have to rely on "magic" commands/flags/options to get it to do what you want. A DSL is an entire language dedicated to magic commands. Why would I want to go through the pain of mastering that, even if the documentation were decent? My current go-to build system for non trivial projects is waf. It's got some really interesting ideas (like describing builds using aspect-oriented programming), but most importantly it has you use straight up Python to write your build scripts. No DSL or special formats. There are other build systems that use general purpose languages to describe builds like premake/xmake which use Lua, Gradle which uses Groovy and Kotlin, or Scons which uses Python (and inspired waf). Personally, I think Python is much more comfortable for working with strings and files, but I'd prefer any of those build systems over something like CMake or Meson.

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 bogwog 5y ago

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.