Understanding autoconf

Developing software that runs on a number of different UNIX and UNIX-like systems requires considerable effort. First, the code itself must be portable. Portable code makes few assumptions about the hardware on which it may be run or the software libraries available to it. In addition, if it’s C code, to ensure maximum portability, the code has to stick to strict ISO/ANSI C, or isolate non-standard C to as few modules as possible.

Second, you need to know a lot about the compile and runtime environments of many different systems and, possibly, hardware architectures. GNU software, while ubiquitous on Linux systems and available for a mind-boggling array of other operating systems and hardware platforms, may not always be available on those systems. In addition, the following
conditions may exist:

• The C compiler may be pre-ISO
• Libraries may be missing key features
• System services may function differently
• Filesystem conventions will certainly be different

On the hardware side, you may have to deal with big-endian, little-endian, or hybrid data representation mechanisms. When you get away from Intel’s x86 processors, you have to deal with, for example, PA-RISC, several varieties of Sparcs, the Motorola chips (in several generations) that drive Macintosh and Apple computers, MIPS, Amiga, and, coming
soon to a computer near you, Intel’s Merced or IA64 chip.

Finally, you have to write a generic makefile and provide instructions to your users on how to edit the makefile to fit local circumstances. autoconf addresses many of these problems. It generates shell scripts that automatically configure source code packages to adapt to many different brands of UNIX and UNIXlike systems. These scripts, usually named configure, test for the presence or absence of certain features a program needs or can use, and build makefiles based on the results of these tests. The scripts autoconf generates are self-contained, so users do not need to have autoconf installed on their own systems in order to build software. All they have to do is type ./configure in the source distribution directory.

To build a configure script, you create a file named configure.in in the root directory of your source code tree. configure.in contains a series of calls to autoconf macros that test for the presence or behavior of features your program can utilize or that it requires. autoconf contains many predefined macros that test for commonly required features. A second set of macros allows you to build your own custom tests if none of autoconf’s built-in macros meet your needs. If need be, configure.in can also contain shell scripts that evaluate unusual or specialized characteristics. Besides the autoconf
package itself (we cover version 2.12), you will need at least version 1.1 of GNU’s m4, a macro processor that copies its input to output, expanding macros as it goes (autoconf’s author, David MacKenzie, recommends version 1.3 or better for speed reasons). The latest versions of both packages can be obtained from the GNU Web site, www.gnu.org, their FTP site, ftp.gnu.org, or from many other locations around the Web. Most Linux distributions contain them, too.

Posted on: 22/07/2010








0 Comments
If you want to leave a comment please Login or Register
How to backup your data using rsync......
Understanding autoconf......
The Basics of fdisk......
Accessing Memory Using DMA......
The fd Directory......