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.
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
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
--htmldir options at
./configure. This is what allows me to skip
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
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).
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? 🙂