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.

This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to vala and autobuild

  1. Maybe the files generated by valac should be listed in the MAINTAINERCLEANFILES[1] variable, which gets only called by the `maintainer-clean`[2] target which seems intended for this exact scope.

    [1] http://www.gnu.org/software/automake/manual/html_node/Clean.html
    [2] http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets

    • Jesse van den Kieboom says:

      Actually, autotools will automatically add all vala generated files to the maintainer-clean target already, so you won’t have to do this manually. So really the confusion was mostly on my part, by not understanding correctly that you’re supposed to distribute the generated files.

  2. I know that this is some form of spam ;) but… why don’t you try “autovala”? It is a software that I created that automatizes and simplifies using CMake and Vala. It is in github: https://github.com/rastersoft/autovala

    • Jesse van den Kieboom says:

      Looks interesting, but as a GNOME project we are really much more comfortable using autotools.

  3. With the latest versions of git.mk, you shouldn’t have to add generated C/H files to GITIGNOREFILES, since git.mk should pick them up automatically. It might not work with non-recursive automake though. If it doesn’t, fixing git.mk would be much better than using GITIGNOREFILES directly!

    • Jesse van den Kieboom says:

      Nice! I must have been using an older git.mk when testing. I’ve just removed a whole bunch of GITIGNOREFILES, thanks for the tip! I think the only files missing currently are generated gir and header files from vala.

Leave a Reply to Jesse van den Kieboom Cancel reply

Your email address will not be published. Required fields are marked *