vala and autobuild

When we switched gitg to Vala, we initially had some problems making the build work correctly. Parallel build especially gave us a lot of headaches. Just so that if someone else runs into the same problems, here are some thoughts on the matter.

We now use (mostly) non-recursive make. This isn’t required or anything, but it is working out great for us and improves build times as well as dependency tracking. It does not take a lot of effort to switch to a non-recursive build. We kept separate Makefile.am in sub directories, but instead of using SUBDIRS we simply include them in the toplevel Makefile.am. You then just need to make sure that variables are properly separated and target specific (i.e. using <target>_VALAFLAGS instead of AM_VALAFLAGS).

gitg is composed of two installed libraries (libgitg and libgitg-ext, where libgitg depends on libgitg-ext), some plugins (also written in Vala) and a program (gitg). Various of these components depend on the libgitg and/or libgitg-ext libraries and I think it’s safe to say that we have a reasonably complex build situation. Only until recently did we manage to make automake understand all these dependencies properly. The main problem was that automake does not properly track dependencies of inter-project vala packages if you specify them with –vapidir and –pkg (which is understandable). Therefore, in parallel build we would end up with libgitg and gitg being valac’d at the same time. This in turn made the build of gitg fail because it depends on libgitg. To solve this, we now instead specify the libgitg-1.0.vapi directly as a source file to the build of gitg. This corrects the dependency resolution such that libgitg is always valac’d before gitg.

Finally, the vala autobuild support works a bit differently than you would normally expect (at least, than I had expected). Although valac will generate .c, .h, .vapi, .gir files etc, all these files are expected to end up in the tarball. Like this, distributed tarballs do not actually require vala at all to compile since all generated sources are included in the archive. automake automatically sets up all the required rules so normally you’re fine. However, we used to add all these generated files to CLEANFILES so that ‘make clean’ would gives us a nice clean tree. Don’t do this! Cleaning up these files breaks assumptions on the state of your working directory and the rules generated by vala automake support doesn’t work correctly in parallel build when you clean up only a subset of the generated files. More specifically, you’d need to also cleanup the .stamp files. Even if you do cleanup everything generated in CLEANFILES, your distcheck will most likely still fail because it doesn’t expect these files to be cleaned by CLEANFILES. Anyway, instead of cleaning them, we now just add all those generated files to GITIGNOREFILES (we use git.mk) and everything seems to be working fine.

If you’re having problems, or just want to have a look, this is our toplevel Makefile.am, libgitg/Makefile.am and gitg/Makefile.am.