(c) 2005,2007 Juha Vierinen jPARSE@THISsgo.fi
One often gets a warm fuzzy feeling seeing the autoconf generated configure file after unpacking a source tarball -- this is because your chances of easily compiling the piece of software have grown significantly. This doesn't mean that you won't have any problems -- you will have problems with compiling software sooner or later -- it just means that things tend to go more smoothly when autoconf and automake (referred to as autotools in this text) are involved. The main purpose of these tools is ease the pain of compiling software on different platforms, but automake can additionally automate many other aspects of software configuration management.
The end user never needs to use autoconf or automake, as these
tools create a plain vanilla sh script called
configure. This way the platform used for compiling
doesn't need to have a working autotools, just a regular bourne shell.
The normal way to proceed after untarring a source package is this:
./configure ; make ; make install
Usually there are also many custom options provided by the package maintainer. The help option usually lists these.
./configure --help
For example, --prefix will install the software into the home directory of the user instead of the default location (/usr or /usr/local).
./configure --prefix=/home/user
> export CFLAGS="-O42 -g --funny-compiler-flag -I/hard/to/guess/directory"
> ./configure ; make # will usually use your CFLAGS for compiling
Sometimes, a package might also include custom arguments to do this as well eg.:
> ./configure --with-blas="-L/home/user -lblas" > ./configure --with-blas="/opt/supafastblaswithstripesandachrometailpipe.a"
The commonly used targets are:
make # Compile everything. make clean # Remove all objects, temporary files and such. make distclean # Remove automatically generated autoconf/automake files. make dist # Create a tar.gz file containing source ready for distribution. make install # Install software to you kit.
make tags # Generate etags files for the source. make dist-zip # Create a zip file (great for windows people) make uninstall # Uninstall the files installed with make install make check # Run tests bundled with the project
autogen.sh # Semi-standard script for generating the configure # script and possibly the Makefile.in files # by running automake and autoconf. configure.[in,ac] # Definitions used for producing configure Makefile.in # Autoconf makefile template Makefile.am # Automake project description file.
screensave.@OBJEXT@: screensave.c
@CC@ @CFLAGS@ -c -o $@ $<
bin_PROGRAMS=hello
hello_SOURCES=hello.c hello.h someotherfile.f manylanguages.cpp
autoscan # Scan your source code to detect which tests might be needed and # create a configure.scan, which can be used as a basis of # configure.in. autoheader # Scan configure.in and create a config.h.in file, that will # be used as a basis of your config.h (if you use one) automake # Go through configure.in and Makefile.am files and create # Makefile.in files. autoconf # Go through configure.in and create the configure script.
You can write tests directly into configure.in. The language is a macro-language called M4, which is used to generate Bourne shell script. So you basically write in a mixture of sh and M4. Eg.
AC_MSG_CHECKING([for answer to meaning of life]) # M4 function call
answer="42" # sh variable assignment
AC_MSG_RESULT($answer) # M4 function call
AC_DEFUN([ACX_BLAS],
[
acx_blas_ok=no
AC_ARG_WITH(blas,
[AC_HELP_STRING([--with-blas=<lib>], [use BLAS library <lib>])])
case $with_blas in
yes | "") ;;
no) acx_blas_ok=disable ;;
-* | */* | *.a | *.so | *.so.* | *.o) BLAS_LIBS="$with_blas" ;;
*) BLAS_LIBS="-l$with_blas" ;;
esac
# Get fortran symbol name of sgemm (a blas routine).
AC_FC_FUNC(sgemm)
acx_blas_save_LIBS="$LIBS"
LIBS="$LIBS $FCLIBS $FLIBS"
# First, check BLAS_LIBS environment variable
if test "x$BLAS_LIBS" != x; then
save_LIBS="$LIBS"; LIBS="$BLAS_LIBS $LIBS"
AC_MSG_CHECKING([for $sgemm in $BLAS_LIBS])
AC_TRY_LINK_FUNC($sgemm, [acx_blas_ok=yes], [BLAS_LIBS=""])
AC_MSG_RESULT($acx_blas_ok)
LIBS="$save_LIBS"
fi
# restore the libs variable
LIBS=$acx_blas_save_LIBS
])
This can be then added to configure.in like this:
sinclude([acx_blas.m4])
ACX_BLAS
LIBS="$BLAS_LIBS $FLIBS"
rm configure ; cvs update configure ; ./configure
Alternatively, you can regenerate the configure yourself, if you have autotools installed:
sh autogen.sh ; ./configure
There is also a semi-official autoconf macro index contains a wide range of tests. They might not be perfect, but usually are a good starting point.
Another useful reference is the code itself. Need to know a shell variable that is produced by some test? Look it up from the autoconf/lib/autoconf directory of autoconf source.
Libtool is another useful tool to learn, for making cross-platform libraries, but libtool is not discussed here.
Autoproject is a tool that creates a skeleton automake and autoconf managed project.