|René Nyffenegger's collection of things on the web|
René Nyffenegger on Oracle - Most wanted - Feedback
- Follow @renenyffenegger
./configure, automake, autoconf and the like
Source code (especially C/C++) must be compiled differently on different platforms. Aggravating is the fact that some (library-) functions are not present on all platform (for example
In order to tackle this problem, GNU proposes a two step build mechanism involving configure, autoconf, automake and the like.
Essentially, it boils down to a standard build process for a program like so:
./configure make make install
./configure also creates a
Lastly, ./configure creates a stamp-h.in file.
On the installer machine, nothing more than a bourne shell, a c compiler and a make programm are needed.
configure's behaviour can be changed through its options.
autoscan can be used to create a configure.scan file which can be used as a starting point for a configure.in file.
Makefile.am is a simple specification of a project's build requirements that will be turned into a fully fledged Makefile.
A typical Makefile.am has the form
Most Makefile.am assigns values to the following variables:
Additionally, for each program, the following variables must be assigned to:
For each library, the following variables must be assigned to:
Usually, the Makefile is generated by ./configure from Makefile.in
acconfig.h is the file out of which config.h.in is generated.
autoheader can be used to create an initial config.h.in.
Use this file when something went wrong with ./configure.
config.status is a shell script that may be used to recreate the current configuration. That is, all generated files will be regenerated.
Can also be used with recheck
How they interact
On this page is a dot generated graphic that illustrates (or at least: tries to) how the tools interact and which files they produce.