It's apparently cool to talk about jhbuild again, so let me tell you the truth: I'm a heavy user of jhbuild. And as such, I probably got used to various issues with this tool and don't see them anymore. However, I do feel it's a bit weird that people often blame it for being complex or not working well while, most of the time, it does work well and the issues are not in jhbuild itself, but in the way people try to use it, or in some bad things happening in repositories... So let me talk a bit more about this amazing tool!

Why still use jhbuild?

When I first built GNOME from scratch, using a development version of a distribution was a bit of a nightmare, and building GNOME from source was really so much easier. That's why I started using jhbuild. However, nowadays, most distributions have a relatively stable development version, where GNOME is updated really fast to the latest version: if you're a GNOME addict, you can easily get your fix this way.

Still, I keep using jhbuild. In a different way, though: I used to run a jhbuilt desktop, while I now mostly run jhbuilt applications for testing. The reason for this is that it makes my life easier when I fix bugs in various modules: I already have the code, I can tweak things and rebuild quickly something to see the result. No need to install weird packages: I did it once, a long time ago, for my jhbuild environment, and I forgot about it. I can also read the GNOME code whenever I want, even when I'm offline (you know, on the train or plane).

Another reason I still use jhbuild is release management. For each release of GNOME, the release team publishes modulesets that can be used to build this specific version of GNOME, and that we use to make sure that everything builds fine, and then to test the desktop. This is the smoketesting step. It turns out to be quite important, as we often find that we need a new tarball to fix the build (see for example my 2.31.92 nightmare — we can often blame maintainers there). It is more worrying when we also find critical bugs while running the jhbuilt desktop this way, but it doesn't happen that much anymore (phew!).

Also, jhbuild makes it easy to build the next version of GNOME: while most distributions are stuck in the 2.x world, you can try building 3.0 now. Try because, as Andre found out, there are some issues at the moment. But you can also just build the latest GNOME Shell this way!

jhbuild buildone is great, but you need the dependencies!

Diego recommends to use jhbuild buildone. That's all fine, and I use it quite a lot too. However, it's important to mention that just running jhbuild buildone without having installed anything else before will obviously fail. And I'm 100% convinced that many people tried this in the past, and gave up on jhbuild because of this.

You need dependencies to build a module. There's no way around this. And you can't blame jhbuild if you just use jhbuild buildone and it fails, really :-) That being said, you don't necessarily need to build the dependencies yourself.

Skipping the build of system libraries, or of GNOME libraries

Probably the most common complaint about jhbuild is that it tries to build many many things, including low-level bits of the system. Yes, this is a bit annoying, as it takes time and some of those low-level bits can fail to build. But if you complete this once, you can live happy with those built dependencies for many months, or even years in some cases, so it's worth the effort.

It turns out there's a faster way: you can skip these bits and install packages from your distribution. Here is what I skip because I'm rebuilding from scratch every few months, and I don't feel I need to build these modules that my distribution provides (this is from my ~/.jhbuildrc):

skip = [ ]
# skip from bootstrap
skip.extend ([ 'python', 'guile' ])
# skip some big external dependencies that can be annoying and that are
# installed system-wide anyway
skip.extend ([ 'mozilla', 'firefox', 'dbus', 'hal', 'avahi',
               'NetworkManager', 'PolicyKit', 'PolicyKit-gnome',
               'libgdiplus', 'mono', 'monodoc', 'nss', 'nspr',
               'sqlite3', 'pulseaudio', 'pysqlite2', 'mono-addins',
               'WebKit', 'polkit', 'DeviceKit', 'DeviceKit-disks',
               'DeviceKit-power', 'libxml2', 'libxslt', 'libgpg-error',
               'libgcrypt', 'expat', 'libtasn1', 'gnutls',
               'libvolume_id', 'libdaemon', 'udisks', 'UPower', 'upower'
])
# skip some gnome stuff that I can't test
skip.extend ([ 'evolution-exchange', 'evolution-mapi' ])

As you can see, I just append modules to the list and I don't remove old stuff (hi DeviceKit!).

Some distributions even provide a package that installs most dependencies automatically: in openSUSE, this is the jhbuild-recommended-deps package. With this, using jhbuild becomes even more painless!

But wait, there's more. If it happens that you need a specific library for a module that didn't get installed, or that you did the jhbuild buildone trick to only build a specific module and miss a lot of dependencies, you'll get an error like this:

checking for WNCKLET... no
configure: error: Package requirements (gtk+-2.0 >= 2.19.7 libwnck-1.0 >= 2.30.5) were not met:

No package 'libwnck-1.0' found

Or if you have a pkg-config file for libwnck, but it's too old:

Requested 'libwnck-1.0 >= 2.30.5' but version of libwnck is 2.30.4

At least in openSUSE (and I guess it's true for most RPM-based distributions, not sure about Debian-based ones and others), you can easily install what's missing: sudo zypper in "pkgconfig(libwnck-1.0) >= 2.30.5". Sure, it sometimes happens that the failure is because of a check that is not pkg-config-based, so that won't always work. But with pkg-config slowly progressing towards world domination, this is less and less the case.

Sidenote: if you find a library that is still not using pkg-config, please file a bug and ask its maintainers to add a pkg-config file. Thanks!

GNOME is required to work (which implies... to build) from git

Last but not least: it occurs that people give up on jhbuild because something really just doesn't build from GNOME. A first possibility is that it's using some flags when building from git, that makes the build a bit stricter. A common pattern here is that *_DISABLE_DEPRECATED flags are set, and with all the deprecations work going on in libraries, it sometimes makes life harder. You can try passing --disable-maintainer-mode to configure to help with this. It turns out you can do this automatically in ~/.jhbuildrc:

autogenargs='--disable-maintainer-mode'

(Or just append --disable-maintainer-mode to what you already have.)

But it can also happen that it's just a real build failure, because the module doesn't build with the latest, say, gobject-introspection (remember the 2.31.92 nightmare). In this case, there is nothing jhbuild can do: that's a bug in the module. We're doing our best to avoid such situations, but they do occur. That's what Andre faced a few days ago when he tried to build the 3.0 moduleset. And this is where you can become an active contributor to the project: file a bug! And if you're able to, why not also create a patch? :-)

Interestingly, for a long time, we didn't have such build issues anymore: everyone was using jhbuild back then. But with the stability of development versions of distributions, this is less the case now. We're working on fixing this, and a big part of the solution is the build bots, but we need more of them and we also need people to monitor them to make sure they do not fail because of other weird issues.

jhbuild is well-maintained

Last but not least, I think it's worth mentioning that jhbuild is well-maintained: Frédéric is doing a great job there, and is extremely reactive. This means that even if you hit a real issue in jhbuild, it will likely get fixed fast :-)

I wanted to share my love for jhbuild; now you know about it :-) I really can't imagine working on GNOME without jhbuild: this tool makes my life easier. Daily.