Autoconf
From Wikipedia, the free encyclopedia
 |
|
| Developer(s) | The GNU Project |
|---|---|
| Stable release | 2.63 / September 10, 2008 |
| Operating system | Cross-platform |
| Type | Programming tool |
| License | GNU GPL |
| Website | [1] |
GNU Autoconf is a tool for producing configure scripts for software on Unix-like computer systems. Configure scripts inspect a user's computer system and configure the software package prior to it being installed. After running a series of automated tests, a configure script generates customised header files and a makefile from pre-written templates. These customised files adapt the software and its installation process to suit the user's system. Together with Automake and Libtool, Autoconf forms the GNU build system. It comprises several tools like Autoheader.
Contents |
[edit] Usage overview
The developer specifies the desired behaviour of the configure script by writing a list of instructions in the GNU m4 language in a file called "configure.ac". A library of pre-defined m4 macros is available to describe common configure script instructions. Autoconf transforms the instructions in "configure.ac" into a portable configure script.
[edit] configure.ac format
The GNU Autoconf manual suggests the following format for the configure.ac file:
- Autoconf requirements
- The AC_PREREQ(version) macro can be used to ensure that a recent enough version of the autoconf program is available to process the configure.ac file
- AC_INIT(package, version, bug-report-address)
- This macro is required in every configure.ac file. It specifies the name and version of the software package for which to generate a configure script and the email address of the developer.
- information on the package
- checks for programs
- checks for libraries
- checks for header files
- checks for types
- checks for structures
- checks for compiler characteristics
- checks for library functions
- checks for system services
- AC_CONFIG_FILES([file...])
- AC_OUTPUT
[edit] History
Autoconf was begun in the summer of 1991 by David Mackenzie to support his work at the Free Software Foundation. In the subsequent years it grew to include enhancements from a variety of authors and became the most widely used build configuration system for writing portable free or open source software.
[edit] Approach
Autoconf is similar to the Metaconfig package used by Perl. The imake system formerly used by the X Window System (up to X11R6.9) is closely related, but has a different philosophy.
The Autoconf approach to portability is to test for features, not for versions. For example, the native C compiler on SunOS 4 did not support ISO C. However, it is possible for the user or administrator to have installed an ISO C compliant compiler. A pure version-based approach would not detect the presence of the ISO C compiler, but a feature testing approach would be able to discover the ISO C compiler the user had installed. The rationale of this approach is to gain the following advantages:
- the configure script can get reasonable results on newer or unknown systems
- it allows administrators to customize their machines and have the configure script take advantage of the customizations
- there is no need to keep track of minute details of versions, patch numbers, etc., to figure out whether a particular feature is supported or not
[edit] Criticism
Autoconf is a pretty old and mature product. While it is still being developed and maintained, there is some criticism that states that Autoconf doesn't follow modern trends — it still uses dated technologies and has a lot of legacy restrictions. In particular, often cited weak points of Autoconf are:
- General complexity of used architecture, most projects use multiple repetitions[1].
- Generated 'configure' is writen in Unix shell and thus Makefile generation is slow. Some projects, such as KDE, tried to work around this issue by introducing distinct Makefile generators written in other languages.[1]
- Complex and bloated generated Makefiles are hard to debug and understand by humans.[2]
- Generated 'configure' uses only manual-driven command-line interface without any standardization.[2]
- Cryptic and non-obvious behavior in many cases.[2]
- Weak backward and forward compatibility.[2]
Due to these limitations, some projects that used GNU Build System started to switch to other build systems:
- KDE project switched to CMake, starting with KDE 4.[1]
- Scribus switched to CMake.[1]
- Blender (software) switched to SCons on 2004-02-15.[3]
[edit] References
- ^ a b c d Neundorf, Alexander (2006-06-21). "Why the KDE project switched to CMake -- and how". http://lwn.net/Articles/188693/.
- ^ a b c d McCall, Andrew (2003-06-21). "Stop the autoconf insanity! Why we need a new build system". http://freshmeat.net/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system.
- ^ http://www.blender.org/development/release-logs/blender-233/build-systems/
[edit] See also
- GNU build system
- pkg-config Detecting package dependencies
- CMake Alternative build system
[edit] External links
- GNU Autoconf home page
- GNU Autoconf macro archive
- The Goat Book homepage (aka the Autobook)
- Tutorial "Learning Autoconf and Automake" by Eleftherios Gkioulekas
- Learning the GNU development tools @sourceforge
- Murray Cumming (of gtkmm fame) produced these succinct Autotool info pages:*one *two.
- Autotoolset home page
- The "Autotools Tutorial" by Alexandre Duret-Lutz introduces Autoconf, Automake, Libtool, and Gettext.
- Free guide to Autotools
|
|||||||||||||||||||
