buildj meets PackageKit

What could be more boring than hunting down dependencies one by one before being able to compile that shiny new source tarball or repository you just cloned?

Until now, I've focused on the benefits of the buildj GNOME build system for developers. But some of the latest features to land in my branch over last week will make going from source to a complete install easier than ever for users and testers by automatically determining and prompting to install required development and toolchain packages via the distribution's own packaging system, thanks to PackageKit.

The great thing is, buildj is smart enough to only acquire missing prerequisites from the distribution (or other dependency sources), henceforth fondly referred to as the cloud, if it can determine that doing so will satisfy the full set of mandatory build requirements:



Doing the Right Thing

The new feature is already pretty sane, and I'm working to ensure more correctness in behaviour:

• If the dependency is already available from a manual installation or via jhbuild, it won't redundantly attempt to go and install the equivalent distribution package.
• Likewise, if an available distribution package version is known to be too old or otherwise incompatible, there will be no attempt to install it.
• Transactionality. If the build goes wrong and the user has no intention of fixing things, offer to remove the newly installed packages where it is safe to do so.

Relation to jhbuild

Astute readers will notice that jhbuild provides some similar functionality to that described. In fact, the new metadata for the build specification is developing with continued inspiration from both the dependency descriptions in jhbuild's modulesets and the distribution specifications from PackageKit's Catalog format.

All this means that in the short term the new metadata should be rich enough to act as a decentralised source of inter-project dependency information that can itself be used to populate jhbuild automatically.

And perhaps with wider adoption of buildj we'll eventually even be able to migrate that data out of the central jhbuild module completely and into the individual project repositories, both within and outside of git.gnome.org, extending the GNOME ecosystem and bringing in a new wave of developers - one of the most exciting stated goals of this Summer of Code project!

What's in a build?

Build systems. Love them or hate them, the process of going from source code to executable binary and redistributable package is facilitated by these complex and often unwieldy tools.

As part of Google Summer of Code 2010, I'll be working with the GNOME project and my mentor Alberto Ruiz to define and develop a new build system, buildj, suited to compiling modules from the GNOME desktop and third party applications based around the GNOME platform.

Some of our goals include:

• Less boilerplate. Hand-editable build definitions that Just Work.
• IDE-friendly. Integration with existing tools.
• IJW cross-platform and cross-compilation support.

Most of all, the aim is to make build systems for simple applications and libraries trivial while catering for more complex projects with a simplified syntax.

Making life easier for developers

One of my first goals is to add support for automatic generation of pkg-config .pc files when building libraries and generation of .desktop files in the case of desktop applications. Although these are simple enough to write manually, it's clear that the fields they contain can be derived from the build system (project title, description, release version).

Automating this process will mean there are two less things for new developers to learn, and will also simplify the procedure for each release, ensuring well-formed .pc and .desktop files. My Ubuntu system shows 11 malformed .desktop files in a almost-new installation. Many of the .pc files shipped with the distribution also have redundant source dependencies left behind from previous releases. We can avoid both of these unfortunate situations with buildj. And that's just the beginning...

No silver bullet

At the same time, I should point out that this is not going to become a general purpose build system overnight. We do aim to avoid the need for autoconf and automake in all common cases but our other goals include modularity and the ability to cooperate with existing tools and environments, particularly in the context of a desktop environment project like GNOME. If this sounds like your kind of build system, I'd love to hear your thoughts and feature requests!