| An Internationalized Software Project With Auto Tools |
| Prev |
Auto Tools Overview |
Next |
Auto Tools Overview
This page briefly explains and summarizes the gnu auto tools and its value for users and developers.
Simple Approach: Manual Compilation
The most simple approach to compile a project is to write a short script, which just compiles all sources. The main disadvantage
is, that everything is compiled. So if during the devlopement one file is changed, all are compiled, which is very time
consuming.
Make
Fortunately there exist a well established solution: 'make'. The make utility (or 'gmake' on some systems) reads a
configuration file (usually calld 'Makefile') and executes it. The Makefile should contain dependency information between
the source code files. So if a header file is changed, only those source files, which depend on the changed header
file, are compiled. The bad side of this, that these dependency information either have to be maintained manually or
by some automatic procession (which has to be implemented).
Furthermore, 'make' allows the user to specify one or more targets, which control the work to be done by 'make'. The names of these
targets should be common among all projects, so that end users are quickly familar with it. Commonly used targets are:
- default or all: compile all changed files or all files, if called for the first time.
- install: install the compiled files.
- uninstall: remove the installed files.
- mostlyclean: remove the files created by 'all', except those, which usually do not need to be recompiled.
- clean: remove the files created by 'all'.
- distclean: also remove the files created by 'configure' (see below).
- maintainer-clean: also remove files shipped with the source tarball, but which can be generated from other files (like the documentation or localization).
- dist: create a gzipped source tar-ball for the end user.
- dist-bzip2: create a bzip2 compressed source tar-ball for the end user.
- update-po: rebuild the po files, which are used by the translators (see gettext chapter).
- update-gmo: rebuild the gmo files, which contain the internationalized strings (see gettext chapter).
So writing a Makefile, which supports these targets can be a tough job. Furthermore, Makefiles usually work in a single
directory, so that modularized sources require several Makefiles.
Another problem is, that several assumptions are platform dependent, like the name of the compiler to use (g++, or c++, or maybe cpp?) or the directories to search libraries in. These have to be found out automatically or specified by the user. Supporting this is
beyond the scope of 'make'.
Configure
To solve this, the gnu build system requires an excutable called 'configure'. If executed, it analyzes the system to answer
all these questions (which compiler? Where to find a liabrary?). User parameters are allowed to help answering this questions.
Afterwards, the Makefile's are created, which reflect the result of the analysis.
To have 'configure' really portable it must be written in a language, available on all or nearly all target platforms
without compilation. Shell script (sh) is a good canididate. Furthermore 'configure' usually needs some template files,
to create the Makefiles from. These are usually called Makefile.in and have to be delivered as well.
So from the user perspective, software installation requires:
- All libraries or other software, the package depends on,
- the necessary compiler,
- the 'make' utility
- and a shell script interpreter.
- After extracting the sources, 'configure' has to be executed, which checks the computer and creates the Makefiles.
- 'make' will compile the packages and
- 'make install' finally installs it.
The developer will mainly use the minimal rebuild property of 'make' and the other make target described above.
Unfortunately the developer has to create the 'configure' script and the Makefile.in's. This task is simpified
by the gnu auto tools. automake and autoconf are its most important.
Autoconf
Gnu autoconf (as well as automake) has to be installed on all developer computers (but not on the end user machines!).
The developer writes a usually very small configuration file (called configure.ac on configure.in), which contains
the necessary actions written in a very short form (see the next chapters). Autoconf will read this file and create a
configure script from it. While the configuration script is usually shorter than a kilo byte, the result script can
be hundreds of kb large!
Automake
Gnu automake works similar. It requires one Makefile.am for each Makefile.in to create. Additionally it requires some
lines in the configure.ac or configure.in. After running automake, Makefile.in's are created, which support all make
targets above, incremental builds and much more. Again typical Makefile.am's are quite short and contain usually
lists of files to compile. The generated Makefile.in's are typical tens of kb in size.
Therefore the developers task is to create these configure.ac (or .in) and the Makefile.am's. automake and
autoconf create the 'configure' script and all Makefile.in's out of it. These are shipped to the user. User and developer
have to run 'configure' to get the necesary Makefile's. These Makefiles also track changes in the Makfile.am's and
configure.ac (or .in) and trigger a rerun of automake, autoconf and 'configure', if necesary! So essentially
the developer can change all the configuration and source code files. A simple 'make' does all necessary steps to
reconfigure and recompile the project!
The remaining chapters mainly explain, how to write the configure.ac and Makfile.am's