GNU Autoconf：Linux自动化配置工具指南

PDF文件

3星 · 超过75%的资源 | 下载需积分: 9 | 2.54MB | 更新于2025-01-30 | 199 浏览量 | 4 评论 | 举报收藏

立即下载

GNU Autoconf 是一组开源工具，用于在不同计算机平台上自动生成软件构建系统的配置脚本，主要应用于Linux发行版中的软件开发流程。它与Automake和Libtool一起构成了一套经典的自动化配置和构建工具集，旨在简化跨平台软件项目的维护和移植。 Autoconf的核心思想是为软件项目提供一个标准的配置方法，使得开发者只需要编写一次配置脚本，即可适应多种不同的操作系统环境。它通过检测预处理器宏和系统特性来确定软件的编译选项，确保软件能够在目标平台上正确编译和链接。 Autoconf主要包括两个主要组件：aclocal和configure。aclocal是一个Perl脚本，负责从预定义的宏中生成Makefile.am（Automake的基础）文件，而configure则是一个由Autoconf生成的自定义配置脚本，它会根据用户的选项和系统环境进行调整，生成Makefile和其他必要的配置文件。 Automake是一个辅助工具，它规范了Makefile的结构，使得Makefile可以更容易地处理依赖关系和目标构建。Automake生成的Makefile能够跨平台地管理编译步骤，提高了构建过程的可移植性。 Libtool则用于处理动态链接库的构建，它提供了一个通用的方式来创建、安装和链接共享库，确保了在不同环境下库的兼容性和一致性。 GNU Autoconf的版权属于Gary Vaughan、Ben Elliston、Tom Tromey和Ian Lance Taylor，首次出版于2000年10月。本书遵循Open Publication License，允许在指定条件下自由分发。此外，书中还包含了版权信息、印刷代码以及关于商标使用的说明。 GNU Autoconf是一个关键的工具链，对于维护和扩展Linux及类Unix系统上的开源项目具有重要意义，通过自动化配置过程，极大地降低了软件开发者的负担，促进了跨平台软件的普及和发展。

using the GNU Autotools relates to building packages in a cross-compilation

environment. Chapter 25

demystifies this.

The appendixes include instructions on installing GNU Autotools, platforms,

generated file dependencies, and an Autocont macro reference.

Appendix E

contains the Open Publication License.

Conventions Used in This Book

Typographical conventions used in this book are as follows:

• A monospaced (Courier) font is used for commands, command-line options,

functions, and all code examples. This font is also used for interactive shell

logs where the results of commands are interspersed with lines typed at a

CLI prompt by the user.

• Bold is used for the emphasis of terms, interactive shell log lines that are

typed by the user, and function names.

• Italics are used for emphasized terms, fields in code examples, variable tags,

and words that are being defined.

• Text following a => symbol indicates a result which is output.

Chapter 1. History

This chapter summarizes the history of the tools described in this book. Although

you do not need to know this history to use the tools, the history of how the tools

developed over time helps explain why the tools act the way that they do today. Also,

in a book such as this, it is only fair for us to credit the original authors and sources

of inspiration and to explain what they did.

1.1 The Diversity of Unix Systems

Of the programs discussed in this book, the first to be developed was autoconf.

The history of the Unix operating system determined its development.

Dennis Ritchie of Bell Labs wrote the first version of Unix in 1969. During the 1970s,

Bell Labs was not permitted to sell Unix commercially, but did distribute Unix to

universities at relatively low cost. The University of California at Berkeley added

their own improvements to the Unix sources; the result was known as the BSD

version of Unix.

In the early 1980s, AT&T signed an agreement permitting them to sell Unix

commercially. The first AT&T version of Unix was known as System III.

As the popularity of Unix increased during the 1980s, several other companies

modified the Unix sources to create their own variants. Examples include SunOS

from Sun Microsystems, Ultrix from Digital Equipment Corporation, and HP-UX from

Hewlett Packard.

Although all the Unix variants were fundamentally similar, various differences

existed between them. They had slightly different sets of header files and slightly

different lists of functions in the system libraries, as well as more significant

differences in areas such as terminal handling and job control.

The emerging POSIX standards helped to eliminate some of these differences. In

some areas, however, POSIX introduced new features, leading to more variants.

Also, different systems adopted the POSIX standard at different times, leading to

further disparities.

All these variations caused problems for programs distributed as source code. Even

a function as straightforward as memcpy was not available everywhere; the BSD

system library provided the similar function bcopy instead, but the order of

arguments was reversed.

Program authors who wanted their programs to run on a wide variety of Unix

variants had to be familiar with the detailed differences between the variants. They

also had to worry about the ways in which the variants changed from one version to

another, as variants on the one hand converged on the POSIX standard and on the

other continued to introduce new and different features.

Although it was generally possible to use #ifdef to identify particular systems and

versions, it became increasingly difficult to know which versions had which features.

It became clear that some more organized approach was needed to handle the

differences between Unix variants.

1.2 The First configure Programs

By 1992, four different systems had been developed to help with source-code

portability:

• The metaconfig program, by Larry Wall, Harlan Stenn, and Raphael

Manfredi.

• The Cygnus 'configure' script, by K. Richard Pixley, and the original GCC

'configure' script, by Richard Stallman. These are quite similar, and the

developers communicated regularly. GCC is the GNU Compiler Collection

(formerly the GNU C compiler).

• The GNU Autoconf package, by David MacKenzie.

• Imake, part of the X Window system.

These systems all split building a program into two steps: a configuration step and

a build step. For all the systems, the build step used the standard Unix make

program. The make program reads a set of rules in a 'Makefile', and uses them to

build a program. The configuration step generates 'Makefile's, and perhaps other

files, which are then used during the build step.

Metaconfig and Autoconf both use feature tests to determine the capabilities of the

system. They use Bourne shell scripts (all variants of Unix support the Bourne shell

in one form or another) to run various tests to see what the system can support.

The Cygnus 'configure' script and the original GCC 'configure' script are also

Bourne shell scripts. They rely on little configuration files for each system variant,

both header files and 'Makefile' fragments. In early versions, the user compiling

the program had to tell the script which type of system the program should be built

for; they were later enhanced with a shell script written by Per Bothner, which

determines the system type based on the standard Unix uname program and other

information.

imake is a portable C program. imake can be customized for a particular system,

and run as part of building a package. It is more normally distributed with a package,

however, including all the configuration information needed for supported systems.

metaconfig and autoconf are programs used by program authors. They produce a

shell script distributed with the program's source code. A user who wants to build

the program runs the shell script to configure the source code for the particular

system on which it is to be built.

The Cygnus and GCC 'configure' scripts, and imake, do not have this clear

distinction between use by the developer and use by the user.

The Cygnus and GCC 'configure' scripts included features to support cross

development, both to support building a cross-compiler (which compiles code to be

run on another system) and to support building a program using a cross-compiler.

autoconf, metaconfig, and imake did not have these features (they were later

added to autoconf); they worked only for building a program on the system on

which they were to run.

The scripts generated by metaconfig are interactive by default: They ask questions

of the users as they go along. This permits them to determine certain characteristics

of the system, which it is difficult or impossible to test, such as the behavior of

setuid programs.

The Cygnus and GCC 'configure' scripts, and the scripts generated by autoconf,

and the imake program, are not interactive; they determine everything themselves.

When using autoconf, the package developer normally writes the script to accept

command-line options for features that cannot be tested for, or sometimes requires

the user to edit a header file after the 'configure' script has run.

1.3 configure Development

The Cygnus 'configure' script and the original GCC 'configure' script both had

to be updated for each new Unix variant they supported. This meant that packages

that used them were continually out of date as new Unix variants appeared. It was

not hard for the developer to add support for a new system variant; however,

package users could not do so easily themselves.

The same was true of Imake as it was commonly used. Although it was possible for

a user to build and configure Imake for a particular system, it was not commonly

done. In practice, packages that use Imake (such as the X Window system) are

shipped with configuration information detailed for specific Unix variants.

Because Metaconfig and Autoconf used feature tests, the scripts they generated

could often work correctly on new Unix variants without modification. This made

them more flexible and easier to work with over time, and led to the wide adoption

of Autoconf.

In 1994, David MacKenzie extended Autoconf to incorporate the features of the

Cygnus 'configure' script and the original GCC 'configure' script. This included

support for using system-specified header file and 'Makefile' fragments, and

support for cross-compilation.

GCC has since been converted to use Autoconf, eliminating the GCC 'configure'

script. Most programs that use the Cygnus 'configure' script have also been

converted, and no new programs are being written to use the Cygnus 'configure'

script.

The metaconfig program is still used today to configure Perl and a few other

programs. imake is still used to configure the X Window system. However, these

tools are not generally used for new packages.

1.4 Automake Development

By 1994, Autoconf was a solid framework for handling the differences between Unix

variants. However, program developers still had to write large 'Makefile.in' files

to use it. The 'configure' script generated by autoconf would transform the

'Makefile.in' file into a 'Makefile' used by the make program.

A 'Makefile.in' file has to describe how to build the program. In the Imake

equivalent of a 'Makefile.in', known as an 'Imakefile', it is only necessary to

describe which source files are used to build the program. When Imake generates a

'Makefile', it adds the rules for how to build the program itself. Later versions of

the BSD make program also include rules for building a program.

Because most programs are built in much the same way, there was a great deal of

duplication in 'Makefile.in' files. Also, the GNU project developed a reasonably

complex set of standards for 'Makefile's, and it was easy to get some of the

details wrong.

These factors led to the development of Automake. automake, like autoconf, is a

program run by a developer. The developer writes files named 'Makefile.am';

these use a simpler syntax than ordinary 'Makefile's. automake reads the

'Makefile.am' files and produces 'Makefile.in' files. The idea is that a script

generated by autoconf converts these 'Makefile.in' files into 'Makefile's.

As with Imake and BSD make, the 'Makefile.am' file needs only to describe the

files used to build a program. automake automatically adds the necessary rules

when it generates the 'Makefile.in' file. automake also adds any rules required by

the GNU 'Makefile' standards.

David MacKenzie wrote the first version of Automake in 1994. Tom Tromey rewrote

it completely in 1995.

1.5 Libtool Development

Over time, Unix systems added support for shared libraries.

Conventional libraries, or static libraries, are linked into a program image. This

means that each program that uses a static library includes some or all of the library

in the program binary on disk.

Shared libraries, on the other hand, are separate files. A program that uses a shared

library does not include a copy of the library; it includes only the name of the library.

Many programs can use a single shared library.

Using a shared library reduces disk-space requirements. Because the system can

generally share a single executable instance of the shared library among many

programs, it also reduces swap-space requirements at runtime. Another advantage

is that it is possible to fix a bug by updating the single shared library file on disk,

without requiring all the programs that use the library to be rebuilt.

剩余387页未读，继续阅读

资源评论

实在想不出来了

2025.06.24

GNU autoconf是开发者必备工具，对于Linux系统开发尤为重要。💪

透明流动虚无

2025.06.10

GNU autoconf在开源世界中扮演了简化配置过程的关键角色。

行走的瓶子Yolo

2025.04.29

虽然受众有限，但对于特定群体如Linux开发者来说，GNU autoconf不可或缺。

首席程序IT

2025.03.25

对于Linux系统软件的跨平台构建，GNU autoconf是绕不开的工具之一。😂

nobel1984

粉丝: 1

GNU Autoconf：Linux自动化配置工具指南

GNU autoconf, automake, and libtool

Autotools -- A Practioner‘s Guide to GNU Autoconf, Automake, and Libtool

autoconf-archive:GNU Autoconf档案库的镜像，它是GNU Autoconf的500多个宏的集合，这些宏已由Internet的友好支持者作为免费软件提供了

GNU Autoconf Automake and Libtool

GNU autoconf，automake和libtoolGNU autoconf, automake and libtool

GNU Autoconf与Automake学习指南

GNU Autoconf & Automake 指南：Autoconf, Automake, Libtool

精通GNU Autoconf, Automake和Libtool

GNU Autoconf, Automake, Libtool详解

GNU Autoconf, Automake, Libtool实战指南

构建GNU Autoconf/Automake配置脚本详解

GNU Autoconf与Automake：轻松生成Makefile

使用GNU Autoconf与Automake构建Makefile教程

使用GNU Autoconf和Automake简化Makefile编写

GNU AUTOCONF：自动化配置工具详解

GNU Autoconf、Automake和Libtool实践指南

使用GNU Autoconf与Automake轻松创建Makefile

GNU Autoconf：创建自动配置脚本指南

perl-Pod-Coverage-TrustPod-0.100005-7.el8.tar.gz

PCL 计算USC并可视化【2025最新版】

perl-REST-Client-273-15.el8.tar.gz

最新资源