4 ms·

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

by 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 cjhanks 10y ago

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.