is that while all versions differ to some degree, in modern-day Unix systems the variance between the APIs for any two versions is small.
Still, if porting software is so difficult, why is there so much free software available for so many versions of Unix? During the first 20 years of Unix's history, software porting was something that often required overnight stints or even weeks of effort. Today, a utility called Autoconf neatly eliminates this work.
To understand how Autoconf does this magic, we must first understand the changes that have occurred to Unix over the years. In the early 1990s, two events made porting much easier: the use of feature-based portability and the invention of the configure script.
Feature-Based Portability
Back when there were only a few Unix variants to contend with, it was common to base portability
on preprocessor define statements that specified a particular version of Unix. Such statements as XENIX, BSD, SUN, USG, and SYSV were common. This is known as
OS-based portability
.
Unfortunately, as Unix continued to evolve, define statements that had previously made sense became incorrect. For example, when Sun went from using a BSD-based kernel to using an SVR4 kernel, software that made decisions based on the vendor's being Sun did not compile or work correctly on SVR4 implementations. By the mid-1980s, these problems became critical due to the ever-expanding pool of Unix variants and the growing amount of software that had to be maintained.
Feature-based portability then stepped in to the rescue. Rather than presuming certain characteristics based on an OS vendor, feature-based portability identifies the OS features (i.e., the APIs) that the software uses and compiles code conditionally based on those features. For example, the define statement HAVE_MADVISE is a feature-based definition
rather than an OS-based one, since it identifies a capability found in any OS. Porting existing code to a new version of Unix entails identifying the features that the OS provides, providing equivalent definitions to the build system, and providing replacement code for features missing from the OS. After the code is ported to many systems, the various ways of solving a problem have been dealt with, and porting comes down to a simple configuration step and a build step.
The Configure Script
Configure scripts (usually written in the Bourne shell, /bin/sh) are designed to root around in the OS and look for clues that tell it what features it has. The end result is a tailored make file, and possibly an include file or two.
The first significant configure script that I know of was written by Larry Wall and designed to configure Perl. This script was named Configure and became part of the Metaconfig package. Metaconfig Configure scripts are interactive and typically require the user to affirm
guesses that it makes about the OS. The initial thrill of watching this script run is soon lost after the process continues for half an hour or longer.
However, David MacKenzie of the Free Software Foundation (FSF) wanted more: He wanted a configure script that didn't require any attention at all. This way it could be run simultaneously on many kinds of machines to aid in the FSF's porting and testing efforts. There was also the desire to automate the end user's software-installation process.
MacKenzie wrote the original versions of his configure script by hand, which made it difficult to reuse. He learned of similar efforts elsewhere at the FSF and at a company named Cygnus Support. Experience had shown that it was valuable to be able to build a configure script based on the needs of a specific program, rather than a monolithic one that supports all programs. The Autoconf package grew from a combination of all these ideas, and it became a common ground for configure-script efforts.
How Aut
oconf Works
Autoconf is based on a shell script wrapper around a macro language known as m4. This obscure macro language is similar in operation to the C preprocessor (cpp) but is much more powerful. Autoconf provides m4 macros that an application (or package) developer can use to
- determine installation paths
- locate tools and utilities
- determine compiler flags
- determine header-file availability
- determine available libraries
- test compilation of code fragments
- execute arbitrary shell-script fragments
- write make files
- write configuration-header files
The package developer informs Autoconf about features that the package requires by providing a file named
configure.in
as input. This file is an m4 script that invokes m4 macros provided by the Autoconf package. This creates a configure shell script that tests for OS features. When the generated configure script is executed, it takes template versions of files with the extension
.in
(e.g.,
Makefile.in
) and edits them to generate a version tailored to the environment. (
See the figure
for more on the files the developer makes and how they are deployed by an end user.)
The power of Autoconf is its ability to take advantage of the collective knowledge and experience of hundreds of software developers porting to the many variants of Unix. Each Autoconf m4 macro encapsulates this knowledge in a shell-script fragment that knows how to test for a particular feature. As Autoconf matures, developers using it automatically pick up portability improvements by simply upgrading to a newer version.
What You See
When you obtain a package that uses Autoconf, it will include (at a minimum) files named
configure
,
Makefile.in
, and, often,
config.h.in
. The configure script processes
Makefile.in
and
config.h.in
into
Makefile
and
config.h
, respectively. To configure and install the pa
ckage in the
/opt/tools
directory tree, the end user executes these simple configure commands:
'configure--prefix=/opt/tools' 'make install'
This supports options that allow tailoring where files are installed. It also determines which features should be included in the package and where special-purpose libraries and files reside. See the listing
"Sample Autoconf Configure.in File"
for a script example of this capability. If you ever happen to forget what these options are, just type configure--help.
Autoconf's Future
Most public-domain software packages now use Autoconf. With its ground swell of support, the future of Autoconf looks bright. Commercial software developers should note that Autoconf decreases the cost of, and increases the reliability of, supporting more OS versions. Software vendors can increase their profit margins and market share by using Autoconf.
As Autoconf continues to be refined, the winners will the users of Autoc
onf; the losers will be those who don't realize the value of this free software.
dnl Ensure that configure is run in correct directory.
AC_INIT(dos2u.c)
dnl Add code to deal with a configuration header file
AC_CONFIG_HEADER(config.h)
dnl Locate C compiler, 'install' and symbolic link utilities
AC_PROG_CC
AC_PROG_INSTALL
AC_PROG_LN_S
dnl Are the header files ANSI C compliant?
AC_HEADER_STDC
dnl Look for header files we know how to use.
AC_CHECK_HEADERS(fcntl.h string.h sys/types.h unistd.h)
dnl Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST
AC_TYPE_OFF_T
dnl Checks for library functions.
AC_FUNC_MMAP
AC_CHECK_FUNCS(madvise mktemp)
dnl Create 'Makefile' from 'Makefile.in' template
AC_OUTPUT(Makefile)
illustration_link (2
6 Kbytes)
Autoconf lets programmers build scripts that tailor an application for a specific version of Unix.
Bob Friesenhahn (Dallas, TX) specializes in Unix- and TCP/IP-networking-related topics. You can contact him by sending e-mail to
bfriesen@simple.dallas.tx.us
.
Autoconf Makes for Portable Software
