Deciding a new Build System for GNOME
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.
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
Current available contenders
WAF
Python based, easy to extend, gnome support.
Quagmire
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
Cons
- Depends on make
- no autoconf replacement support yet
CMake
KDE4 choice, support for generating XCode packages and frameworks and VisualStudio project files
Proposed Roadmap
Item |
Status |
Comments |
Decide features we need to do a migrate |
to do |
|
Create a table of proposed build systems x features |
to do |
|
Check the KDE build system migration and see what we can learn |
to do |
TimJ has some comments about this |
An obvious option will eventually appear |
to do |
|
Start migrate some modules |
to do |
|