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
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!