3 ms·

I do use CMake as my build system, It is like torture ! literally, I always liked waf, I am curious why not many people use it ? it is incredible, I have very h

by 0xFFC 10y ago

I do use CMake as my build system, It is like torture ! literally, I always liked waf, I am curious why not many people use it ? it is incredible, I have very high hopes for waf and Meson.

slavik81 10y ago
The built-in rules are nice but have you tried doing anything fancy with waf? I wanted to define a rule that would transform an input file into a output file using a tool that was built from source at build-time, then use that output file as a dependency for a unit test. After spending a full week mucking around with waf, I gave up. CMake was much easier for me to understand. Sure, the language is hot garbage, but the mental model of how it functions is simpler. I did something similar to the above and it took an afternoon of learning.
ktRolster 10y ago
I do use CMake as my build system, It is like torture ! I don't want to diminish your experience, but I think you might be doing something wrong there. It doesn't need to be torture.
- mschuetz 10y ago
  I'm having the same problem with CMake. Adding a third party library was an intense challenge. CMake isn't easy.
  - ktRolster 10y ago
    Now that you've done it, how long will it take you to add a third-party library next time?
cjhanks 10y ago
As a user who primarily uses SCons, I feel like my opinion of Waf is reasonably fair. 1. Developers trying to use Waf never realized that they were supposed to check-in the python BLOB into the repository rather than using a system package. Consequently developers would find a lot of regressions in the syntax for builds. 2. Developers had to add the root of the project to their ${PATH} for it to work properly. This may not seem like much... but if you don't know better, it takes people by surprise. 3. Build scripts simply broke between Waf versions too often. Perhaps you can blame this on package mantainers... or maybe distribution maintainers. 4. There was never an overwhelmingly compelling case for `waf configure`. `cmake CMakeLists.txt` borrowed syntax from the C preprocessor which people were comfortable with. `autotools` had thousands of recipes for `./configure`. And adding configuration options to `scons` via command line options always worked just fine. 5. Using the Python language encouraged developers to implement actions which were not idempotent resulting in changes which were not properly tracked by Waf. 6. The code provided no obvious benefits to SCons aside from a little speed, and it was light years slower than CMake, autotools, or simple GMake.
- bjourne 10y ago
  1 & 3. You are supposed to ship the waf script with the code. It's 100kb so it's not a huge burden to check it into your repo. I'm very sure it is explained in the waf book: https://waf.io/book/ https://waf.io/book/ 2. Either run "chmod +x waf ./waf build" or "python waf build" Adding directories to $PATH isn't necessary. 4. I think the use case for configuring and building with the same tool is very compelling. Like: def configure(ctx): ctx.check_cfg(package='gtk+-2.0', args='--cflags --libs', uselib_store = 'GTK-2.0') def build(ctx): ctx.program(source = 'blah.c', target = 'blah', use = 'GTK-2.0') This will add a configure check using pkg-config ensuring that gtk+ is installed. Then due to the use declaration in the call to the program() method, the correct compile and link flags will be added. Because it is all in one tool, it is very easy. Other build systems complicates it by keeping configure and build separate. 5. True, but I prefer more power over less. 6. Tomas Nagy published some benchmarks here: http://www.freehackers.org/~tnagy/bench.txt http://www.freehackers.org/~tnagy/bench.txt Waf was 12 times faster than SCons and about 20% slower than make.

by 0xFFC 10y ago

I do use CMake as my build system, It is like torture ! literally, I always liked waf, I am curious why not many people use it ? it is incredible, I have very high hopes for waf and Meson.

slavik81 10y ago

The built-in rules are nice but have you tried doing anything fancy with waf? I wanted to define a rule that would transform an input file into a output file using a tool that was built from source at build-time, then use that output file as a dependency for a unit test. After spending a full week mucking around with waf, I gave up. CMake was much easier for me to understand. Sure, the language is hot garbage, but the mental model of how it functions is simpler. I did something similar to the above and it took an afternoon of learning.

ktRolster 10y ago

I do use CMake as my build system, It is like torture ! I don't want to diminish your experience, but I think you might be doing something wrong there. It doesn't need to be torture.

mschuetz 10y ago
I'm having the same problem with CMake. Adding a third party library was an intense challenge. CMake isn't easy.
- ktRolster 10y ago
  Now that you've done it, how long will it take you to add a third-party library next time?

cjhanks 10y ago

As a user who primarily uses SCons, I feel like my opinion of Waf is reasonably fair. 1. Developers trying to use Waf never realized that they were supposed to check-in the python BLOB into the repository rather than using a system package. Consequently developers would find a lot of regressions in the syntax for builds. 2. Developers had to add the root of the project to their ${PATH} for it to work properly. This may not seem like much... but if you don't know better, it takes people by surprise. 3. Build scripts simply broke between Waf versions too often. Perhaps you can blame this on package mantainers... or maybe distribution maintainers. 4. There was never an overwhelmingly compelling case for `waf configure`. `cmake CMakeLists.txt` borrowed syntax from the C preprocessor which people were comfortable with. `autotools` had thousands of recipes for `./configure`. And adding configuration options to `scons` via command line options always worked just fine. 5. Using the Python language encouraged developers to implement actions which were not idempotent resulting in changes which were not properly tracked by Waf. 6. The code provided no obvious benefits to SCons aside from a little speed, and it was light years slower than CMake, autotools, or simple GMake.

bjourne 10y ago
1 & 3. You are supposed to ship the waf script with the code. It's 100kb so it's not a huge burden to check it into your repo. I'm very sure it is explained in the waf book: https://waf.io/book/ https://waf.io/book/ 2. Either run "chmod +x waf ./waf build" or "python waf build" Adding directories to $PATH isn't necessary. 4. I think the use case for configuring and building with the same tool is very compelling. Like: def configure(ctx): ctx.check_cfg(package='gtk+-2.0', args='--cflags --libs', uselib_store = 'GTK-2.0') def build(ctx): ctx.program(source = 'blah.c', target = 'blah', use = 'GTK-2.0') This will add a configure check using pkg-config ensuring that gtk+ is installed. Then due to the use declaration in the call to the program() method, the correct compile and link flags will be added. Because it is all in one tool, it is very easy. Other build systems complicates it by keeping configure and build separate. 5. True, but I prefer more power over less. 6. Tomas Nagy published some benchmarks here: http://www.freehackers.org/~tnagy/bench.txt http://www.freehackers.org/~tnagy/bench.txt Waf was 12 times faster than SCons and about 20% slower than make.