To reiterate and illuminate a bit, our options include
1. Autotools + btool. Some hassles, but very widely used and allows us to cover a *lot* of end-user platforms that we've not expected. * project overview: https://www.ohloh.net/p/autoconf * project overview: https://www.ohloh.net/p/automake
2. CMake. Very robust, widely used, and even has commercial endeavors for. Negatives include a more customized, limited scripting language. Note that many consider the more limited language a strength. * project overview: https://www.ohloh.net/p/cmake * in-depth interview: http://twit.tv/floss111
3. Waf. Fairly new, one-man project. Being new has the advantage of allowing it to start with refined ideas, but the one-man situation has major issues including some that Krzysztof touched on. Being modeled after SCons also brings up some warning flags. It also has decreasing year-over-year development activity. * project overview: https://www.ohloh.net/p/waf
4. Forking our own version of Waf. Removes the one-man problems with Waf, but introduces many many many many more.
5. SCons. Not a viable solution. When we've explored build systems before, I'd been unable to get even simple SCons projects working on OS X (including hacking at SCons sources themselves). KDE dropped SCons for CMake for many reasons, including poor cross-platform support. * project overview: https://www.ohloh.net/p/scons
At the moment CMake sounds like the best choice, *if* changing away from our current build system would be worth it. We want to be sure not to underestimate all that our current build system *is* successfully doing at the moment as that tends to be less noticeable. As KDE discovered with SCons, getting a project fully there is a different level of detail than getting smaller sub-projects and tests over.
This article has some good details on switching to CMake, and even includes a sidebar draw from Scribus' Peter Linnell:
Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/