DevHelp is a really nice tool to have available, so let's get it to build! The latest version depends on WebKit2 (the webkit2gtk3 module which doesn't work yet) so first of all we have to pin it to the last version that supported WebKit1 (module name webkit1gtk3). In addition, there are some M4 macros in that version that aren't properly set up, so building from Git is broken. That means that we use the tarball on modulesets as well. It requires gsettings-desktop-schemas, for which we add a module. Also, it will build without shared-mime-info, but then the doc pages will display as HTML source code, rather than HTML. So effectively, shared-mime-info is a dependency as well.
This is not a problem on the pinned revision of JHbuild, but newer versions don't pass --libdir anymore by default. However, if you are using the system Python and don't pass --libdir, then you will install your libxml2 Python module in the system Python modules directory under /Library. This doesn't fail the build, because of $(DESTDIR), but it also doesn't install the Python module in the right place.
This gives introspectable modules an after dependency on gobject-introspection. That ensures that if you _are_ building gobject-introspection, then it gets built in time to generate GIR bindings for Pango, ATK, and GdkPixbuf. If that doesn't happen, then GTK can fail when generating its own GIR bindings.
When building a Python native module, the Waf build system will override your CFLAGS with whatever CFLAGS Python thinks you need. If you don't build Python from jhbuild, you're using the system Python which is a multi-arch binary, and so Waf will force your pycairo module to be multi-arch as well. That doesn't work when linking against Cairo which is not multi-arch. This works around Waf adding -arch flags to the command line and allows our gtk-osx-build -arch flag to take precedence.
Newer jhbuild seems to want a module called "automake" which it adds automatically as a dependency to every autotools module. I'm not sure that's a great idea, but calling the current version of the Automake module "automake" increases compatibility without harming anything, so that's what I've called it.
…b-nonsrcdir. Matching other berkeleydb-dependent packages.