The autotools collection is a set of tools that make it easy to build and install programs from a source distribution:

autoconf

The autoconf documentation starts off with a fun quote about the nature of God, trying to determine if he was a physicist, an engineer or a computer scientist. The punchline is "And the Chaos, where do you think it was coming from, hmm?".

Much chaos seems to persist in the documentation of the various autotools (part of the GNU Build System). I don't know how others sort it out. I am inclined to think that they just copy an example and ignore or don't check the warnings. This page is started out of a desire to find and note how to use the autotools using the latest versions of the tools on Debian 3.1 and out of frustrations with inconsistancies between various documentations of the system. -- JacobAnawalt


Documentation

The main problem with most autotools documentation is that it is difficult to find examples that are based on the current versions of the tools. The difficulty ranges from not finding any documentation at all (hint: you need to include non-free to get the info page about autoconf) to finding documentation that still uses deprecated examples.

Newer Sources

(As of 2005-07-11)

Older Sources


Notes

AC_CONFIG_HEADER(S) AM_CONFIG_HEADER(S)

The automake documentation's hello world example uses some deprecated macros. While more recent versions note this, I wonder why the example is not updated and why various versions seem to disagree about what is depricated.

automake-1.7.info.gz through automake-1.9.info.gz say that the syntax shown for the AC_INIT and AM_INIT_AUTOMAKE is deprecated. Older versions do not. (So you will not see this if you just type info automake.) It then points to the Public macros section. There AM_CONFIG_HEADER is noted as being obsolete and a synonym for AC_CONFIG_HEADERS. In Public macros under AM_INIT_AUTOMAKE a good example of updating configure.ac is given. (Version 1.9.6, 9 July 2005 at sourceware.org has moved AM_CONFIG_HEADER to a new obsolete macros section).

Running autoscan can create configure.scan. In there I noticed that it uses AC_CONFIG_HEADER instead of the documented AC_CONFIG_HEADERS. It also puts AC_PREREQ(VERSION) before AC_INIT which is technically OK, but discouraged in the autoconf documentation.

automake version

Since automake1.4 provides a higher alternatives priority than later versions of automake you will have to take some steps to call the versions that understand AC_CONFIG_HEADER. /usr/share/doc/autotools-dev/README.Debian.gz gives some suggestions for doing this, though they are mostly focused towards a DebianDeveloper. I would like to use the latest version via update-alternatives, but get lots of warnings about underquoted definitions in /usr/share/aclocal/ with autoreconf when automake1.8 or automake1.9 are selected via alternatives.

Even with the default version, 1.4, running with all warnings will note that several macros in /usr/share are obsolete like AC_OUTPUT_COMMANDS and AC_TRY_COMPILE. There's not a lot for an end-user/developer to do about that and still stick with the DebianSarge packages.

I chose to use automake1.7. (But I must be missing an alternatives step or there's a bug because info automake points at 1.6)

gettextize '' autopoint '' version control of autogenerated files

I started trying to learn more about the autotools build system when I checked out a program from CVS and tried building it. It needed to have configure generated. As I went through this process at some point I was told that lib/ was deprecated. Since that seemed to be a copy of stuff that was on my system anyway, at least in my situation I agreed with that direction.

While working on updating the configure.ac file, autoreconf complains that I have AM_GNU_GETTEXT defined but not AM_GNU_GETTEXT_VERSION. There is a bug report about this but searching into it more helped me dig up some ideas for dealing with gettext/autopoint files in CVS (or another version control system.)

In the Distributed CVS node of gettext, it suggests having all the auto generated files under CVS and only having one developer occasionally update it. The Files under CVS node of the gettext info file gives an overview of the pros and cons of three different approaches of dealing with the auto generated gettext/autopoint files. The info doc for automake-1.7 in section 26.1.3 (FAQ: CVS and generated files) also touches on this concept.

While would normally lean towards including no autogenerated in version control, there is one strong point to include them. If various developers will have different versions of the autotools, it is possible that bugs can be hidden and everyone may not be building what is going to be released. If I am unable to feel confidant that macros like AM_GNU_GETTEXT_VERSION can limit this then it seems that putting all the files under version control is the right thing to do.