Because Automake and Libtool are essentially add-on components to the original Autoconf framework, it's useful to spend some time focusing on using Autoconf without Automake and Libtool. This will provide a fair amount of insight into how Autoconf operates by exposing aspects of the tool that are often hidden by Automake.
Before Automake came along, Autoconf was used alone. In fact, many legacy open source projects never made the transition from Autoconf to the full GNU Autotools suite. As a result, it's not unusual to find a file called configure.in (the original Autoconf naming convention) as well as handwritten Makefile.in templates in older open source projects.
In this chapter, I'll show you how to add an Autoconf build system to an existing project. I'll spend most of this chapter talking about the fundamental features of Autoconf, and in Chapter 4, I'll go into much more detail about how some of the more complex Autoconf macros work and how to properly use them. Throughout this process, we'll continue using the Jupiter project as our example.
The input to the autoconf program is shell script sprinkled with macro calls. The input stream must also include the definitions of all referenced macros—both those that Autoconf provides and those that you write yourself.
The macro language used in Autoconf is called M4. (The name means M, plus 4 more letters, or the word Macro.[36]) The m4 utility is a general-purpose macro language processor originally written by Brian Kernighan and Dennis Ritchie in 1977.
While you may not be familiar with it, you can find some form of M4 on every Unix and Linux variant (as well as other systems) in use today. The prolific nature of this tool is the main reason it's used by Autoconf, as the original design goals of Autoconf stated that it should be able to run on all systems without the addition of complex tool chains and utility sets.[37]
Autoconf depends on the existence of relatively few tools: a Bourne shell, M4, and a Perl interpreter. The configuration scripts and makefiles it generates rely on the existence of a different set of tools, including a Bourne shell, grep, ls, and sed or awk.[38]
Note
Do not confuse the requirements of the Autotools with the requirements of the scripts and makefiles they generate. The Autotools are maintainer tools, while the resulting scripts and makefiles are end-user tools. We can reasonably expect a higher level of installed functionality on development systems than we can on end-user systems.
The configuration script ensures that the end user's build environment is configured to properly build your project. This script checks for installed tools, utilities, libraries, and header files, as well as for specific functionality within these resources. What distinguishes Autoconf from other project configuration frameworks is that Autoconf tests also ensure that these resources can be properly consumed by your project. You see, it's not only important that your users have libxyz.so and its public header files properly installed on their systems, but also that they have the correct versions of these files. Autoconf is pathological about such tests. It ensures that the end user's environment is in compliance with the project requirements by compiling and linking a small test program for each feature—a quintessential example, if you will, that does what your project source code does on a larger scale.
Can't I just ensure that libxyz.2.1.0.so is installed by searching library paths for the filename? The answer to this question is debatable. There are legitimate situations where libraries and tools get updated quietly. Sometimes, the specific functionality upon which your project relies is added in the form of a security bug fix or enhancement to a library, in which case vendors aren't even required to bump up the version number. But it's often difficult to tell whether you've got version 2.1.0.r1 or version 2.1.0.r2 unless you look at the file size or call a library function to make sure it works as expected.
However, the most significant reason for not relying on library version numbers is that they do not represent specific marketing releases of a library. As we will discuss in Chapter 7, library version numbers indicate binary interface characteristics on a particular platform. This means that library version numbers for the same feature set can be different from platform to platform, which means that you may not be able to tell—short of compiling and linking against the library—whether or not a particular library has the functionality your project needs.
Finally, there are several important cases where the same functionality is provided by entirely different libraries on different systems. For example, you may find cursor manipulation functionality in libtermcap on one system, libncurses on another, and libcurses on yet another system. But it's not critical that you know about all of these side cases, because your users will tell you when your project won't build on their system because of such a discrepancy.
What can you do when such a bug is reported? You can use the Autoconf AC_SEARCH_LIBS macro to test multiple libraries for the same functionality. Simply add a library to the search list, and you're done. Since this fix is so easy, it's likely the user who noticed the problem will simply send a patch to your configure.ac file.
Because Autoconf tests are written in shell script, you have a lot of flexibility as to how the tests operate. You can write a test that merely checks for the existence of a library or utility in the usual locations on your user's system, but this bypasses some of the most significant features of Autoconf. Fortunately, Autoconf provides dozens of macros that conform to Autoconf's feature-testing philosophy. You should carefully study and use the list of available macros, rather than write your own, because they're specifically designed to ensure that the desired functionality is available on the widest variety of systems and platforms.
[36] As a point of interest, this naming convention is a fairly common practice in some software engineering domains. For example, the term internationalization is often abbreviated i18n, for the sake of brevity (or perhaps just because programmers love acronyms).
[37] In fact, whatever notoriety M4 may have today is likely due to the widespread use of Autoconf.
[38] Autoconf versions 2.62 and later generate configuration scripts that require awk in addition to sed on the end user's system.