1. Deciding a new Build System for GNOME

1.1. Current problems with the autotools toolchain

• Hard to learn: a few different languages and tons of conventions (M4, make, .am, .in), being one of the most annoying obstacles for new contributors.
• Really hard to parse programaticaly: stopping proper GUI and IDE support (although Anjuta has some support for it).
• Really hard to extend: M4 function definition is hard to learn and for proper support everything has to go mainstream through the FSF.
• Hard to maintain: lack of discipline and experience can turn an autoconf and automake script into a really hard to understand piece of code.
• Hard to port out of a UNIX system: setting up a windows environment for an autotools package is a hazard, hard stopper for windows contributions and automated building and packaging.

1.2. Requisites for a replacement

• Free software
• One single language to use for configure and build time.
• Platforms: unix/win32/osx, avoid unix dependencies such as bash/awk/sed
• Should not be harder to learn than autotools
• Needs to integrate with jhbuild
• Should be possible to extend (eg Vala support)
• i18n: gettext/intltool must be possible
• pkg-config support
• gtk-doc support
• Templates like glib-mkenum
• Need to support building of tarballs (make dist)
• Documented, Tutorial and a Manual

Wishlist, things that are nice to havebut they should not stop the initial migration:

• Cross-compilation
• Building of binary win32 (msi) and OSX (bundle) packages
• Avoid copyright assignments for upstream contribution
• Should allow builds where source dir != build dir

1.3. Current available contenders

1.3.1. WAF

Python based, easy to extend, gnome support.

1.3.2. Quagmire

1.3.2.1. Pros

• No new external dependencies or new build-time dependencies. Just include the quagmire.mk file in your module.
• Not yet another new language to learn.
• Keeps the familiar ./configure, make, make install idiom.
• No need for Gnome to sign off on it: as no dependency blessing is required. Modules can just move to it when they are ready. Include the version you want to use.
• Compatible with a number of existing Gnome i10n make files including gnome-doc-utils. It's just Makefiles.
• KISS

1.3.2.2. Cons

• Depends on make
• no autoconf replacement support yet

1.3.3. CMake

KDE4 choice, support for generating XCode packages and frameworks and VisualStudio project files

1.4. Proposed Roadmap