1 Introduction

Large software packages, especially open-source (OSS) ones, must be highly portable so as to maximize their use on as many systems as possible. Past techniques for ensuring that software can build cleanly and run identically on many systems include the following:

• Asking users to manually configure a package prior to compilation by editing a header file to turn on or off package features or to specify services available from the platform on which the package will be run. This process required intimate knowledge of the system on which the package (e.g., C-News) was to be built.

• Trying to achieve portability using CPP macros and nested #ifdef statements. Such code results in complex, system-specific, deeply-nested CPP macros which are hard to maintain.

• Using Imake [2], a system designed specifically for building X11 applications. Imake defines frozen configurations for various systems. However, such static configurations cannot account for local changes made by administrators.

• Using Metaconfig [11], developed primarily for building Perl. This system executes simple tests similar to Autoconf, but users are often asked to confirm the results of these tests or to set the results to the proper values. Metaconfig requires too much user interaction to select or confirm detected features and it cannot be extended as easily as Autoconf.

GNU Autoconf [5] solves the above problems by providing canned tests that can dynamically detect various features of the system on which the tests are run. By actually testing a feature before using it, Autoconf and its sister tools Automake [6] and Libtool [7] can build packages portably without user intervention. These automated software configuration tools (autotools [10]) can run on numerous systems. Autotools work identically regardless of the OS version, any local changes that administrators installed on the system, which system software packages were installed or not, and which system patches were installed.

The rest of this paper is organized as follows. Section 2 explains the motivation for automated software configuration tools. In section 3 we explain how GNU Autoconf and associated tools work, explore their limitations, and describe how we used these tools. Section 4 evaluates several large OSS packages and details the use of autotools in the Am-utils package. We conclude in Section 5.