Desert Moon

Last spring I evaluated waf as an alternative to SCons (and its 3rd party Qt4.py plugin) for Qt4 projects. I’ve finally settled on CMake.

waf’s wscript files could be beautifully concise. Alas, support for Qt4 applications was unstable, and the support for building OS X application bundles was both rudimentary and unstable. (By “unstable” I mean that the qt4 and osx tools would break periodically, and/or that the internal APIs would change so much between releases that my own customizations would break.)

The final straw was that I could not control the library order when linking static Qt4 libraries. That made it impossible for me to build Qt4 apps which used QtSvg.

I wish I had time to document these problems properly — no doubt waf’s maintainer(s) would prefer bug reports to detail-free claims that “it doesn’t work.”

In any case, CMake seems to be doing the job. It can perform out-of-line builds, supports defining and running unit tests, and doesn’t get in the way of writing integration tests in Python, to drive e.g. C++ programs. It knows how to build Qt4 applications and lets me control the link order for static libraries. And it works well on OS X and Linux.

I’m evaluating waf to see if it’s easier to use than SCons (especially for Qt projects). So far the results are encouraging. In particular, waf reports many kinds of problems using straightforward (color-coded!) error messages, rather than Python tracebacks.

target ‘build_info’ does not exist

Sometimes waf does spew an unintelligible Python traceback reminiscent of SCons. For me, these typically end with a KeyError:

File "/path/to/.waf-1.3.2-blah/wafadmin/Task.py", line 290, in must_run
    prev_sig = tree.m_sig_cache[key][0]
KeyError: -214303645

This error always translates to “you are trying to build a file which is part of your source tree.”

My SConscripts work in situ, creating object files etc. in the same directories where the source code resides. waf prefers to put build products in a separate build/ subdirectory. When waf is instructed to generate an output file in its build tree, and when that file already exists in the source tree, waf fails with the KeyError traceback.

I’d bet this problem is most common in software projects which started life using build systems like Make or SCons — tools which default to building in situ.

For example, I’m trying to use waf in a subversion workspace where I’ve been doing SCons builds for years. To make matters worse, one of the build products is a header file, containing revision number and date for the current build. This looks like a source file, so it’s likely that I never checked whether it was properly removed by scons -u -c.

In retrospect, I should have started with a clean check-out…