Setting up software for distribution can be a daunting task. Most of the the time, a well written makefile does the trick. Sometimes a little more is needed - or even expected. The GNU autotools for setting up a software distribution can help iron out some of the problems a programmer might run into.
Using autotools for a very simple piece of software still requires a few steps:
The Enlightenment Thumbnailing Utility or etu makes use of a simple (but powerful) scaling API for jpeg images. Initially, etu was comprised of very few files:
There are also some test images, however, they are not used for building in any way.
Makefile is relatively simple (as it is in
the case of etu) then it can just be moved to
Running autoscan without results in the following:
[mui@vela:~/proj/etu-notools$] ls configure.scan etu.c Makefile README test-images/ test.jpg ... [mui@vela:~/proj/etu-notools$] autoscan autom4te: configure.ac: no such file or directory autoscan: /usr/bin/autom4te failed with exit status: 1
One nice thing, however, it generates a
configure.scan file which can be used as a starting
point. First, the
configure.scan is copied to
configure.in and edited.
The file sets up the checks to be performed, most of these are self explanatory:
# Process this file with autoconf to produce a configure script. AC_PREREQ(2.59) AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS) AC_CONFIG_SRCDIR([etu.c]) # Checks for programs. AC_PROG_CC AC_PROG_INSTALL # Checks for libraries. # Checks for header files. AC_HEADER_DIRENT AC_HEADER_STDC AC_CHECK_HEADERS([stddef.h stdlib.h string.h unistd.h]) # Checks for typedefs, structures, and compiler characteristics. # Checks for library functions. AC_FUNC_CLOSEDIR_VOID AC_FUNC_STAT AC_CHECK_FUNCS([mkdir]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT
Anyone who has viewed the source code for etu knows there is
already one problem, there is no check for the
file. This can be remedied by simply adding an entry to the
Checks for header files section, under the
AC_CHECK_HEADERS([stddef.h stdlib.h string.h unistd.h Epeg.h])
Next it is time to run autoconf - those paying close attention may notice there is an error coming:
[mui@vela:~/proj/etu-notools$] ./configure checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed configure: error: cannot find install-sh or install.sh in . ./.. ./../..
install.sh file isn't actually needed, the
easiest way around this is to create a placeholder (besides, it may
be needed at some point later).
echo "Do nothing - a placeholder for autofoo" >> install.sh
Now when autoconf runs, everything works. Note that the
Epeg.h header is checked for:
... checking Epeg.h usability... yes checking Epeg.h presence... yes checking for Epeg.h... yes ...
At the point where
./configure works, it is time to
test it in a platform where it should fail. The distribution
was copied into a NetBSD system that does not even have X windows
checking Epeg.h usability... no checking Epeg.h presence... no checking for Epeg.h... no
So there it is, it will not work on this system and a notice was put out.
GNU tools do like a few other files although they are not required. In general it is nice (but not required) to add:
Again, none of the above listed files are required unless a particular project needs them - but they are nice to have.
Using autotools even on a basic program (such as etu which is about as basic as it gets) can help to move a program from system to system without too much fuss. This article only touched on how to set up a simple autotools based distribution, hopefully in the future a more in depth look will be done here, however, in the meantime please take a read of the GNU Build manual for more details.