3.1 A simple example, start to finish

Let’s suppose you just finished writing zardoz, a program to make your head float from vortex to vortex. You’ve been using Autoconf to provide a portability framework, but your Makefile.ins have been ad-hoc. You want to make them bulletproof, so you turn to Automake.

The first step is to update your configure.in to include the commands that automake needs. The way to do this is to add an AM_INIT_AUTOMAKE call just after AC_INIT:

AC_INIT(zardoz, 1.0)
AM_INIT_AUTOMAKE
...

Since your program doesn’t have any complicating factors (e.g., it doesn’t use gettext, it doesn’t want to build a shared library), you’re done with this part. That was easy!

Now you must regenerate configure. But to do that, you’ll need to tell autoconf how to find the new macro you’ve used. The easiest way to do this is to use the aclocal program to generate your aclocal.m4 for you. But wait... maybe you already have an aclocal.m4, because you had to write some hairy macros for your program. The aclocal program lets you put your own macros into acinclude.m4, so simply rename and then run:

mv aclocal.m4 acinclude.m4
aclocal
autoconf

Now it is time to write your Makefile.am for zardoz. Since zardoz is a user program, you want to install it where the rest of the user programs go: bindir. Additionally, zardoz has some Texinfo documentation. Your configure.in script uses AC_REPLACE_FUNCS, so you need to link against ‘@LIBOBJS@’. So here’s what you’d write:

bin_PROGRAMS = zardoz
zardoz_SOURCES = main.c head.c float.c vortex9.c gun.c
zardoz_LDADD = @LIBOBJS@

info_TEXINFOS = zardoz.texi

Now you can run automake --add-missing to generate your Makefile.in and grab any auxiliary files you might need, and you’re done!