When I’m composing this blog post (a few days in advance of its publication), I just took a little forced break (because I’m missing some tool I can’t find) from hacking at autotools buildsystems.
In particular, I’m hacking at Lennart’s projects, mostly because I bumped libasyncns and noticed I could make the ebuild simpler if I changed a few things in there.
My target with this hacking session is to update the build systems to the latest version of autoconf (2.62), making use of some new features that can make it easier to handle the packages during ebuilds. I’ll be discussing here some of the changes because, first, I know Lennart won’t mind if I dissect his autotools-fu 😉 and second because it makes a nice “documentation” to show how to properly use autotools. If you want to check the changes I actually made, you can find all the repositories on my git server; Lennart’s projects are the ones under 0pointer directory.
The first feature I wanted to make use of was the presence of htmldir and docdir variables in the newer versions of autoconf (2.60 and later, if I recall correctly, certainly not 2.59). These two variables allow to declare in Makefile.am some files as text or HTML documentation, letting the user (or the ebuild) choose where to install those through --docdir and --htmldir options at ./configure. This is what allows me to skip dodoc and dohtml commands in the ebuild, as the build system will take care of installing everything.
Another useful feature of the newest versions is that the AC_HEADER_ASSERT macro now provides a --disable-assert option that can be used to disable the assert() function calls in software without having to add manually -DNDEBUG to your flags. Unfortunately this does not work perfectly as it expects that every source file includes config.h before any other include (the same requirement exists for AC_SYS_LARGEFILE for what it’s worth), but luckily Lennart’s projects are well written. Not all projects support disabling assert(), even though it’s supposed to be just a debug facility, a few projects don’t take extra measures ot make sure the code continue working fine and safe without them.
But there are more things I changed, to improve the readability, and not only of autotools. For instance I replaced the custom CFLAGS testing code with code that uses CC_CHECK_CFLAGS macro, which is available in the attributes.m4 macro file available on xine-lib’s repository (that macro file was originally developed by me for unieject and has been now copied over multiple projects.. I always try to keep it in sync). This makes it possible to cache the result of the tests on availability of CFLAGS, and allows for new compilers, supporting a GCC-like commandline, to work out of the box. Similarly, C99 language checks are replaced with AC_PROG_CC_C99 that takes care of discovering how the compiler supports C99.
More tied to Lennart’s code is the creation of a ZP_LYNX_DOC macro, in its own macro file, instead of adding on all the configure.ac files the code to handle --disable-lynx and the conditional. It is very useful to factor out these common pieces of code in their own macros, as it allows to just copy a file over when you need to fix them, or improve them, rather than having to cut copy and paste code, with the risk of making bigger mistakes.
And a suggestion for those of you who want to test an autotooled package out of git or another development repository: if it’s possible, use autoreconf -is instead of the standard autoreconf. This avoids copying over the macro and support files from /usr/share to your work directory, symlinking them instead. This reduces disk occupation and should also be faster to re-generate.
Unfortunately for now autoreconf does not seem to support extra extensions to autotools, like intltool or gtkdoc and you have thus to choose between executing them by hand, or using the bootstrap scripts that the developers provided (which is bad in ebuilds).
What autoreconf should be is a standardised bootstrapping script that takes care of using the right tools with the right options for one’s project. Unfortunately with the existence of tools like intltool and similar, that extend the basic autotools syntax, and don’t seem to be “accepted” by upstream, it starts to become overly useless. I suppose an option would be to create a generic, installable, autoreconf-syntax semi-compatible script that could be used instead of the various custom bootstrap and autogen scripts for the projects.
Anybody with some free time to start hacking at that? 🙂