2010/1/8 Krzysztof Kosiński <tweenk.pl@...400...>: OK, it looks like you put some thought into choosing the system and it's really a tradeoff between features.
To sum up, Waf is similar in principle to SCons (scripts are Python), but its different architecture allows it to be faster. However, its code isn't great, it's mostly undocumented, and the maintainer isn't easy to work with. The best that could happen is if someone forked Waf, refactored and documented it. But this might not be realistic. I think Waf 1.5 is still less pain to use than Autotools.
As the merits and demerits were mostly discussed already I would like to point out that lack of design, documentation and maintainer cooperation are exactly the things I hate about software, any software.
I saw only one other project using waf and I had a problem building it. The waf scripts did not produce any error messages whatsoever when a test failed so I had to look at the sources and run the command manually to see how it is failing.
I reported it to the maintainer of the project who said that waf has no facilities for reporting errors so I should report it to waf maintainer. As I am not a waf user myself I was somewhat reluctant but found that there is a waf issue already reported about that resolved as wontfix. As the project author thinks that adding error reporting to every test is too much work there will be likely no error reporting for that project, ever. Perhaps it should be done in a separate module which is used by the tests, who knows. Lack of documentation ..
That's not to say that waf cannot be used effectively, especially if one is committed to customizing it when it is lacking in some areas. Using customized version of a piece of software tends to be somewhat problematic but every build system seems to come with its own problems.
Thanks
Michal