O O Ø O O O O

Go to the next section.

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by Free Software Foundation.

Some background on autoconf

Autoconf is a set of tools (the programs are actually called autoconf, autoheader, autoscan, autoreconf, autoupdate, ifnames) which helps make your code configurable and portable to various versions of UNIX.

You probably have had the experience of installing a typical GNU utility, such as GNU Emacs. You might remember that, even though emacs is a gigantic and complex program, the installation procedure consisted symply of typing something like:

gzcat emacs-19.30.tar.gz | tar xvf -
cd emacs-19.30
./configure --prefix=/packages              # or whatever prefix you use
gmake install

and that was all the active work you had to do.

The autoconf tools help you prepare your software in this manner.

The autoconf documentation is quite complete and detailed, but it does not contain any simple concrete examples to get a beginner off the ground. I recently taught myself how to use autoconf on new programs and how to convert existing programs.

I taught myself by converting Gnudl and Dominion to use autoconf. Then I converted xyplot to autoconf and in doing that took notes. The notes, with a few embelishments, are what you find here. This document should allow you to take your old programs and add configure scripts to them, so that they will have that robustness and configurability.

Some other background details:

There are two other automatic configuration systems: Larry Wall's metaconfig (used by rn, perl, patch...) and the X Window Consortium's imake utility. Both are also very good, but I have a strong preference for autoconf. The reasons are pretty much those stated in the autoconf manual, so I will not repeat them here.
People writing GNU utilities (and other tools) usually use autoconf and follow many of the GNU coding standards (there is a document describing those as well). There are debateable points in the GNU coding standards, but overall they really make large software packages easy to install and maintain. I will call a program that uses the GNU coding standards and autoconf GNUlitically correct, and I mean it as a compliment: GNUitically correct programs are usually quality pieces of software, and when I install a program with a good configure script, I usually think "Aha, this is probably a good program".
Many people, including myself, have come up with clever ideas for their `Makefile' and `config.h' files; ways to use the C preprocessor to decide which architecture we are on. I had come up with a foolproof way of guessing all architectures I had access to (which was very many versions of UNIX) for the dominion distribution. But little changes in new revisions would foil my scheme, and I saw that I was not that clever. Also, it was a lot of work. I have since converted dominion to use autoconf, and it is much more robust this way.

Go to the next section.