I’ve been playing around with waf in the last couple of weeks. My first contribution was helping Richard Hughes to port PackageKit to waf. We did 90% of the work in a couple of hours just guessing from the examples in the demos/ directory of the waf repository. Note that it took me a couple of weeks to accomplish a similar work with autotools with the same level of understanding.

Yesterday I started to extend the java tool, I added support for the JAVA_HOME environment variable and class_checking support. I wrote both patches in less than an hour. My next steps are adding support for manifest attributes for the jar files, and a better classpath elements handling. Thomas gently granted me write access to the waf repositories, so it looks that suddenly I’m a waf developer.

So far, the experience is pretty pleasant, I would like to see more stable releases in the future though, and maybe some autotools arg compatibility module (for –datadir, –configdir and the like) and It absolutely needs testing on more platforms, but it’s so easy to fix that it’s worth.

Regarding the discussion about porting GNOME to something else than autotools, I think that people asking maintainers to do it are losing some perspective on how important it is to keep what we have, there’s a lot of knowledge on our autoconf/automake scripts, so this can’t be done from day 0, and it can’t be a "waf xor autotools" approach, I think that a parallel effort of a small set of waf experts adding waf support to some modules is the best approach, we can get a lot of testing from there and we don’t need to break things.

One interesting focus here is the Windows builds, one of the reasons that prevents building GNOME from jhbuild on windows is that it’s painful to setup a sane environment due to require of a unix shell and make. Waf can play an important role here to allow a more pleasant Windows testing and development experience.

So, if you’re a GNOME maintainer, and you’re interested in exploring a new world of faster builds and easier maintainability, just poke us at #waf@irc.freenode.net, take a look at our wiki page or join to our mailing list.

Coming soon: a waf tutorial post.



2 thoughts on “Waf-ness

  1. The problem with all those script based building systems (and this includes automake as you can insert scripts there, too) it that IDEs (like anjuta) have no real chance to parse the information and to create a GUI to configure the project.
    It is only possible with lots of assumptions (we do that for automake) and it breaks if someone decides to create a more complicated build environment.


  2. @Johannes:
    waf supports input xml files, however, it’s going to be pretty hard to define a parseable format before the tools get more mature and stable
    it wouldn’t be that hard to serialize the existing scripts to that file format once defined, so waf is not really a stopper for that on the long-term
    however, for the short term, it sensibly improves the maintainer experience, the learning path and the portability compared with what we have at the moment
    but I do agree that smooth IDE integration is a must for the mid/long term of a replacement


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s