常用的 Makefile 建置目標

3.3 The most useful Makefile targets / 常用的 Makefile 建置目標

By now `configure' has generated the output files such as a `Makefile'. Most projects include a `Makefile' with a basic set of well-known targets (see section 4.1 Targets and dependencies). A target is a name of a task that you want make to perform -- usually it is to build all of the programs belonging to your package (commonly known as the all target). From your build directory, the following commands are likely to work for a configured package:

截至目前為止，我們已經提到 `configure' 會產生一些輸出檔，比如 `Makefile' 檔案。大部分的專案會準備一個內建有常見建置目標的 `Makefile' 檔案 (請見 4.1 建置目標與相依性)。一個建置目標是一個你希望 make 幫你完成的工作的名稱 -- 比如，建置所有套件中的程式 (常見的 all 建置目標)。在已經完成套件組態的建置資料夾中，通常可以使用以下的指令:

make all

Builds all derived files sufficient to declare the package built.

建置出所有足使這個套件發揮功能的必要檔案。

make check

Runs any self-tests that the package may have.

執行在套件內所準備的自我測試程式。

make install

Installs the package in a predetermined location.

將套件檔案安裝到預先設定好的路徑中。

make clean

Removes all derived files.

刪除所有在建置過程中所產生的檔案。

There are other less commonly used targets which are likely to be recognized, particularly if the package includes a `Makefile' which conforms to the GNU `Makefile' standard or is generated by automake. You may wish to inspect the generated `Makefile' to see what other targets have been included.

還有一些比較少用到但是通常有支援的建置目標，特別是那些遵守了 GNU `Makefile' 標準或是由 automake 所產生的 `Makefile' 檔案。要知道所產生的 `Makefile' 支援了哪些建置目標，你可能需要看看所產生出來的 `Makefile' 檔案的內容。

由 configure 所產生的檔案

3.2 Files generated by configure / 由 configure 所產生的檔案

After you have invoked `configure', you will discover a number of generated files in your build tree. The build directory structure created by `configure' and the number of files will vary from package to package. Each of the generated files are described below and their relationships are shown in C. Generated File Dependencies:

在執行 `configure' 之後，你會發現有一些檔案在你的建置資料夾中被產生出來。在不同的套件中，由 `configure' 在建置資料夾所建立的資料夾結構以及檔案的數量會稍有不同。以下簡述所產生的檔案的功能，這些檔案間的關係則在 C. 所產出檔案間的相依性中描述:

`config.cache'

`configure' can cache the results of system tests that have been performed to speed up subsequent tests. This file contains the cache data and is a plain text file that can be hand-modified or removed if desired.

`configure' 可以藉由儲存系統測試程式的結果，來縮短後續測試所耗的時間。所儲存的快取資訊會以純文字的形式存放在這個檔案中，如果有需要的話，可以手動編修或移除這個檔案。

`config.log'

As `configure' runs, it outputs a message describing each test it performs and the result of each test. There is substantially more output produced by the shell and utilities that `configure' invokes, but it is hidden from the user to keep the output understandable. The output is instead redirected to `config.log'. This file is the first place to look when `configure' goes hay-wire or a test produces a nonsense result. A common scenario is that `configure', when run on a Solaris system, will tell you that it was unable to find a working C compiler. An examination of `config.log' will show that Solaris' default `/usr/ucb/cc' is a program that informs the user that the optional C compiler is not installed.

在 `configure' 執行時，會印出一些訊息來描述正在執行的測試，以及測試的結果。實際上，由 shell 以及 `configure' 所執行的工具程式會送出更多的訊息，但是為了讓印到輸出畫面的資訊較容易被使用者理解，這些額外的訊息不會被送到輸出畫面上。所有額外的訊息會被導向到 `config.log' 檔案中，當 `configure' 程式作出怪異的行為或是產生莫名奇妙的測試結果時，這個檔案是第一個該看看的地方。一個常見的例子是，在 Solaris 系統上執行 `configure' 時顯示找不到可以使用的編譯器的訊息。在檢視 `config.log' 後就會發現，在 Solaris 上所預先安裝的 `/usr/ucb/cc' 是一個顯示 C 編譯器尚未安裝的程式，並非是一個可用的編譯器。

`config.status'

`configure' generates a shell script called `config.status' that may be used to recreate the current configuration. That is, all generated files will be regenerated. This script can also be used to re-run `configure' if the `--recheck' option is given.

`configure' 會產生一個稱為 `config.status' 的 shell 指令稿，這個指令稿可以用來重新建立目前的組態環境。換言之，這個指令稿會重新產生所有 `configure' 所產生的檔案。另外，只要在執行時給定 `--recheck' 的選項，也可以透過這個指令稿來重新執行 `configure' 程式。

`config.h'

Many packages that use `configure' are written in C or C++. Some of the tests that `configure' runs involve examining variability in the C and C++ programming languages and implementations thereof. So that source code can programmatically deal with these differences, #define preprocessor directives can be optionally placed in a config header, usually called `config.h', as `configure' runs. Source files may then include the `config.h' file and act accordingly:

許多使用 `configure' 的套件是由 C 或 C++ 所撰寫的，有許多 `configure' 所執行的測試正是用來檢驗執行建置程序的 C/C++ 編譯器所提供的語言實作細節，以及檢驗諸如函式庫的版本或存在與否等編譯環境所提供支援的程度。測試所得的結果可以由 #define 前置處理指引的方式表現出來，通常會存放到檔名為 `config.h ' 的設定標頭檔中。在程式的原始碼中就可以引入 `config.h' 並且針對各個狀況來撰寫特定的程式碼片段分別處理，比如:

#if HAVE_CONFIG_H # include #endif /* HAVE_CONFIG_H */ #if HAVE_UNISTD_H # include #endif /* HAVE_UNISTD_H */

We recommend always using a config header.

我們建議所有的專案都應該使用設定標頭檔。

`Makefile'

One of the common functions of `configure' is to generate `Makefile's and other files. As it has been stressed, a `Makefile' is just a file often generated by `configure' from a corresponding input file (usually called `Makefile.in'). The following section will describe how you can use make to process this `Makefile'. There are other cases where generating files in this way can be helpful. For instance, a Java developer might wish to make use of a `defs.java' file generated from `defs.java.in'.

其中一個 `configure' 常被用到的功能是產生 `Makefile' 檔，或是其他有用的檔案。正如同之前所提到的，一個 `Makefile' 檔通常會是一個由 `configure' 分析一個對應的輸入檔 (通常會是 `Makefile.in') 所產生，接下來的章節會描述如何執行 make 來使用 `Makefile' 檔案。類似的方法也可以用在其他場合來產生有用的檔案，比如，一個 Java 程式設計師可能會想從一個 `defs.java.in' 來產生出 `defs.java' 檔。

進行組態

3.1 Configuring / 進行組態

A `configure' script takes a large number of command line options. The set of options can vary from one package to the next, although a number of basic options are always present. The available options can be discovered by running `configure' with the `--help' option. Although many of these options are esoteric, it's worthwhile knowing of their existence when configuring packages with special installation requirements. Each option will be briefly described below:

`configure' 指令稿接受一大堆的命令列選項，不同的套件所能夠接受的選項會不太一樣，有一些基本的選項在所有套件中都可以找到，各套件所可以接受的選項可以透過執行 `configure' 時加上 `--help' 選項取得。雖然有不少的選項通常不會被用到，但有特殊的需求時，知道一下這些選項的存在會很有幫助。以下簡述在所有套件中都能找到的基本選項:

`--cache-file=file'

`configure' runs tests on your system to determine the availability of features (or bugs!). The results of these tests can be stored in a cache file to speed up subsequent invocations of configure. The presence of a well primed cache file makes a big improvement when configuring a complex tree which has `configure' scripts in each subtree.

`configure' 會在你的系統執行測試程式以檢查系統所能提供的功能 (或是系統的錯誤與漏洞)，測試的結果會被存在一個快取檔案中，以縮短未來執行 configure 所耗用的時間。一些複雜的專案的原始碼樹在每個子資掉夾都有各自的 `configure' 指令稿，在這個情況下，可以透過留置快取檔案來大幅縮減組態所耗用的時間。

`--help'

Outputs a help message. Even experienced users of `configure' need to use `--help' occasionally, as complex projects will include additional options for per-project configuration. For example, `configure' in the GCC package allows you to control whether the GNU assembler will be built and used by GCC in preference to a vendor's assembler.

輸出說明訊息，因為一些複雜的專案會在 `configure' 中加入一些額外的選項，因此即使是有經驗的使用者偶而也需要使用 `--help' 選項。比如，在 GCC 套件的 `configure' 中就可以讓你控制是不是要建置 GNU 組譯器並讓 GCC 使用，或是要使用其他廠商所提供的組譯器。

`--no-create'

One of the primary functions of `configure' is to generate output files. This option prevents `configure' from generating such output files. You can think of this as a kind of dry run, although the cache will still be modified.

`configure' 的主要功能之一是產生用來建置套件的檔案，給定這個選項會讓 `configure' 不產生那些檔案，但快取檔仍會被修改，你可以將這個功能視為進行測試用的功能。

`--quiet'
`--silent'

As `configure' runs its tests, it outputs brief messages telling the user what the script is doing. This was done because `configure' can be slow. If there was no such output, the user would be left wondering what is happening. By using this option, you too can be left wondering!

在 `configure' 進行測試時，他會輸出一些簡單的訊息告訴使用者指令稿正在做什麼。因為 `configure' 的執行會花很多時間，如果沒有輸出這些東西，使用者只能在旁邊瞎猜現在的狀況。只要給定了這個選項，你就可以重新加入大家來瞎猜的行列。

`--version'

Prints the version of Autoconf that was used to generate the `configure' script.

印出產生這個 `configure' 指令稿的 Autoconf 版本。

`--prefix=prefix'

The --prefix option is one of the most frequently used. If generated `Makefile's choose to observe the argument you pass with this option, it is possible to entirely relocate the architecture-independent portion of a package when it is installed. For example, when installing a package like Emacs, the following command line will cause the Emacs Lisp files to be installed in `/opt/gnu/share':

--prefix 是經常被使用的一個選項，如果所產生的 `Makefile' 會嚴格遵守你隨著這個選項所傳入的參數，那麼就可以把整個套件中與硬體平台無關的部分安裝到預設路徑外的地方去。比如說，利用以下的指令安裝 Emacs 套件，會讓 Emacs 的 Lisp 檔案安裝到 `/opt/gnu/share' 之下:

$ ./configure --prefix=/opt/gnu

It is important to stress that this behavior is dependent on the generated files making use of this information. For developers writing these files, Automake simplifies this process a great deal. Automake is introduced in 7. Introducing GNU Automake.

很重要的一點是，所產生的檔案必須要會使用這項資訊。對於撰寫設定檔的開發者，使用 Automake 可以大幅簡化這個步驟，我們會在 7. GNU Automake 簡介中介紹 Automake。

`--exec-prefix=eprefix'

Similar to `--prefix', except that it sets the location of installed files which are architecture-dependent. The compiled `emacs' binary is such a file. If this option is not given, the default `exec-prefix' value inserted into generated files is set to the same value as the `prefix'.

這個選項與 `--prefix' 類似，但所指定的路徑位址是給與硬體平台相關的檔案使用的，比如所編譯出來的 `emacs' 執行檔。如果這個選項沒有給定，預設的 `exec-prefix' 值會被設定為 `prefix' 的值。

`--bindir=dir'

Specifies the location of installed binary files. While there may be other generated files which are binary in nature, binary files here are defined to be programs that are run directly by users.

給定要安裝執行檔的路徑位置，套件建置可能會產生很多各式各樣的執行檔，但這個選項所指的執行檔僅包含會被使用者直接執行的程式。

`--sbindir=dir'

Specifies the location of installed superuser binary files. These are programs which are usually only run by the superuser.

給定要安裝管理員用執行檔的路徑位置，這些程式通常只由系統管理員使用。

`--libexecdir=dir'

Specifies the location of installed executable support files. Contrasted with `binary files', these files are never run directly by users, but may be executed by the binary files mentioned above.

給定要安裝可執行的支援檔案的路徑位置，與上面所提及的 `執行檔' 所不同，被這個選項所指的檔案不會被使用者直接的執行，但可能會被上面所說的執行檔所執行。

`--datadir=dir'

Specifies the location of generic data files.

給定要安裝一般性的資料檔的路徑位置。

`--sysconfdir=dir'

Specifies the location of read-only data used on a single machine.

給定在單一機器上的設定資料的路徑位置，這些設定資料對一般使用者是唯讀的，且一般而言不同的機器會有不同的設定。

`--sharedstatedir=dir'

Specifies the location of data which may be modified, and which may be shared across several machines.

給定共用可讀寫資料的路徑位置，這些資料檔可以被使用者所更改，並且可能會在數臺不同的機器所共享。

`--localstatedir=dir'

Specifies the location of data which may be modified, but which is specific to a single machine.

給定專屬可讀寫資料的路徑位置，這些資料檔可以被使用者所更改，但只會由一臺機器存取使用。

`--libdir=dir'

Specifies where object code library should be installed.

給定安裝函式庫目的碼的路徑位置。

`--includedir=dir'

Specifies where C header files should be installed. Header files for other languages such as C++ may be installed here also.

給定安裝 C 標頭檔案的路徑位置，如 C++ 等其他語言所使用的標頭檔也可能會被安裝在這個選項所指定的路徑下。

`--oldincludedir=dir'

Specifies where C header files should be installed for compilers other than GCC.

給定安裝給非 GCC 的其他編譯器所使用的 C 標頭檔案的路徑位置。

`--infodir=dir'

Specifies where Info format documentation files should be installed. Info is the documentation format used by the GNU project.

給定安裝 Info 格式文件檔的路徑位置，Info 是被 GNU 計畫所使用的文件檔案格式。

`--mandir=dir'

Specifies where manual pages should be installed.

給定安裝使用手冊的路徑位置。

`--srcdir=dir'

This option does not affect installation. Instead, it tells `configure' where the source files may be found. It is normally not necessary to specify this, since the configure script is normally in the same directory as the source files.

這個選項不會影響到安裝，但可以裡用這個選項告訴 `configure' 套件原始碼所在位置。通常並不需要設定這個選項，因為 configure 指令稿通常會與原始碼放在一樣的資料夾內。

`--program-prefix=prefix'

Specifies a prefix which should be added to the name of a program when installing it. For example, using `--program-prefix=g' when configuring a program normally named `tar' will cause the installed program to be named `gtar' instead. As with the other installation options, this `configure' option only works if it is utilized by the `Makefile.in' file.

給定要在安裝個別執行檔時接到預設程式檔名之前的前置字串，比如，在組態 tar 套件時使用 `--program-prefix=g' 會讓正常情況下稱為 `tar' 的程式被更名為 `gtar'。就像其他的安裝選項，這個 `configure' 選項只在 `Makefile.in' 有使用到這個設定時才有效。

`--program-suffix=suffix'

Specifies a suffix which should be appended to the name of a program when installing it.

給定要在安裝個別執行檔時接到預設程式檔名之後的後置字串。

`--program-transform-name=program'

Here, program is a sed script. When a program is installed, its name will be run through `sed -e script' to produce the installed name.

在這裡的 program 是一個 sed 指令稿，在安裝個別執行檔時，預設的執行檔名會送進 `sed -e script' 以產生各執行檔的檔名。

`--build=build'

Specifies the type of system on which the package will be built. If not specified, the default will be the same configuration name as the host.

給定執行套件建置的系統平台名稱，如果這個選項沒有給定，預設將會使用與 host 相同的值。

`--host=host'

Specifies the type of system on which the package will run--or be hosted. If not specified, the host triplet is determined by executing `config.guess'.

給定將執行或安裝套件程式的系統平台名稱，如果這個選項沒有給定，預設將會執行 `config.guess' 來取得系統平台名稱。

`--target=target'

Specifies the type of system which the package is to be targeted to. This makes the most sense in the context of programming language tools like compilers and assemblers. If not specified, the default will be the same configuration name as the host.

給定套件的目標系統平台，這個選項在建置如編譯器或組譯器等程式語言工具時會較有意義。如果這個選項沒有給定，預設將會使用與 host 相同的值。

`--disable-feature'

Some packages may choose to provide compile-time configurability for large-scale options such as using the Kerberos authentication system or an experimental compiler optimization pass. If the default is to provide such features, they may be disabled with `--disable-feature', where feature is the feature's designated name. For example:

有些套件會讓使用者在編譯時期決定是不是要將像 Kerberos 認証系統之類較龐大的額外功能，或是實驗性的編譯時期最佳化選項納入建置。如果這些額外的功能預設是開啟的，那麼可以利用 `--disable-feature' 來將他們關閉，在這邊 feature 應代換為功能的代稱，例如:

$ ./configure --disable-gui

`--enable-feature[=arg]'

Conversely, some packages may provide features which are disabled by default. To enable them, use `--enable-feature', where feature is the feature's designated name. A feature may accept an optional argument. For example:

相反的，有些套件會將額外的功能預設為關閉。使用 `--enable-feature' 可以啟用這些額外的功能，在這邊 feature 應代換為功能的代稱。有些功能可以接受額外的參數，例如:

$ ./configure --enable-buffers=128

Using `--enable-feature=no' is synonymous with `--disable-feature', described above.

使用 `--enable-feature=no' 跟使用上面提到的 `--disable-feature' 會有相同的效果。

`--with-package[=arg]'

In the free software community, there is a healthy tendency to reuse existing packages and libraries where possible. At the time when a source tree is configured by `configure', it is possible to provide hints about other installed packages. For example, the BLT widget toolkit relies on Tcl and Tk. To configure BLT, it may be necessary to give `configure' some hints about where you have installed Tcl and Tk:

儘可能利用既有的套件與函式庫是自由軟體社群中一項健康的潮流，當利用 `configure' 對原始碼樹進行組態時，這個選項可以用來提供一些系統既有套件的資訊。例如 BLT widget toolkit 需要 Tcl 與 Tk 事先安裝在系統上，在組態時可能需要給 `configure' 一些關於 Tcl 與 Tk 安裝位置的提示:

$ ./configure --with-tcl=/usr/local --with-tk=/usr/local

Using `--with-package=no' is synonymous with `--without-package' which is described below.

使用 `--with-package=no' 與使用將在下面提到的 `--without-package' 會有相同的效果。

`--without-package'

Sometimes you may not want your package to inter-operate with some pre-existing package installed on your system. For example, you might not want your new compiler to use GNU ld. You can prevent this by using an option such as:

有時候你可能會不希望你建置的套件程式去使用系統內已安裝的套件，比如說，你可能不想讓新的編譯器使用 GNU ld 來連結程式。你可以用像下面這樣的選項來達到這個目的:

$ ./configure --without-gnu-ld

`--x-includes=dir'

This option is really a specific instance of a `--with-package' option. At the time when Autoconf was initially being developed, it was common to use `configure' to build programs to run on the X Window System as an alternative to Imake. The `--x-includes' option provides a way to guide the configure script to the directory containing the X11 header files.

這個選項其實是 `--with-package' 的一個特例。在 Autoconf 的開發初期, `configure' 常被用來作為 Imake 外的另一個建置 X Window System 應用程式的選擇。透過 `--x-includes' 選項，使用者可以告知 configure 指令稿 X11 的標頭檔所在的資料夾。

`--x-libraries=dir'

Similarly, the --x-libraries option provides a way to guide `configure' to the directory containing the X11 libraries.

與前項相似，透過 `--x-libraries' 選項，使用者可以告知 configure 指令稿 X11 函式庫檔所在的資料夾。

It is unnecessary, and often undesirable, to run `configure' from within the source tree. Instead, a well-written `Makefile' generated by `configure' will be able to build packages whose source files reside in another tree. The advantages of building derived files in a separate tree to the source code are fairly obvious: the derived files, such as object files, would clutter the source tree. This would also make it impossible to build those same object files on a different system or with a different configuration. Instead, it is recommended to use three trees: a source tree, a build tree and an install tree. Here is a closing example of how to build the GNU malloc package in this way:

在原始碼樹中執行 `configure' 是不必要也不被建議的，到原始碼樹之外的資料夾中執行 `configure' 來產生 `Makefile' 檔案並建置套件會比較好。在與原始碼樹分離的資料夾建置套件的優點是顯而易見的: 諸如目的檔等由建置程序所產生的檔案，將不會混雜到原始碼樹之中。此外，也可以在與原始碼樹分離的數個資料夾中分別進行建置動作，如此一來能讓一套原始碼可同時用來建置出給不同系統使用的執行檔，或是針對不同的組態分別進行建置作業。因此，我們建議的做法是在每次的建置作業中使用到三個不同的資料夾: 原始碼樹、建置資料夾以及安裝資料夾。以下是一個使用這個方法來建置 GNU malloc 套件的例子:

$ gtar zxf mmalloc-1.0.tar.gz $ mkdir build && cd build $ ../mmalloc-1.0/configure creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking host system type... i586-pc-linux-gnu checking build system type... i586-pc-linux-gnu checking for ar... ar checking for ranlib... ranlib checking how to run the C preprocessor... gcc -E checking for unistd.h... yes checking for getpagesize... yes checking for working mmap... yes checking for limits.h... yes checking for stddef.h... yes updating cache ../config.cache creating ./config.status

Now that this build tree is configured, it is possible to go on and build the package and install it into the default location of `/usr/local':

現在，建置資料夾已經組態完成，接下來就可以使用以下指令來進行建置作業，並將成品安裝到預設的安裝資料夾 `/usr/local' 中:

$ make all && make install

如何執行 configure 與 make

3. How to run configure and make / 如何執行 configure 與 make

A package constructed using Autoconf will come with a `configure' script. A user who wants to build and install the package must run this script in order to prepare their source tree in order to build it on their particular system. The actual build process is performed using the make program.

一個使用 Autoconf 建構的套件會含有一個 `configure' 指令稿，想要建置與安裝套件的使用者必須先執行這個指令稿，以針對使用者的系統調整所取得的原始碼樹。實際的建置程序，則是利用 make 程式來執行。

The `configure' script tests system features. For example, it might test whether the C library defines the time_t data type for use by the time() C library function. The `configure' script then makes the results of those tests available to the program while it is being built.

`configure' 指令稿會測試系統所支援的功能，舉例來說，他可能會測試 C 函式庫是不是定義了由 time() 這個 C 函式庫使用的 time_t 資料型別。完成測試後 `configure' 指令稿會把結果包裝成建置時期可以存取的型式，以供建置時使用。

This chapter explains how to invoke a `configure' script from the perspective of a user -- someone who just wants to take your package and compile it on their system with a minimum of fuss. It is because Autoconf works as well as it does that it is usually possible to build a package on any kind of machine with a simple configure; make command line. The topics covered in this chapter include how to invoke configure, the files that configure generates and the most useful `Makefile' targets -- actions that you want make to perform -- that will be available when compiling the package (see section 4. Introducing `Makefile's).

在這章，我們會從使用者 -- 也就是想在他自己的系統上取得你的套件並編譯，但不希望碰上大麻煩的那個人 -- 的角度來解釋怎麼執行 `configure' 指令稿。拜 Autoconf 的精良實作，我們通常可以在任何機器上執行簡單的 configure; make 指令來進行套件的建置。我們會在這章討論怎麼執行 configure，哪些檔案會被 configure 產生，以及一些在編譯套件時很有用的 `Makefile' 建置目標 -- 也就是你想要 make 進行的動作 (請參閱 4. 簡介 `Makefile')。

Microsoft Windows

2.6 Microsoft Windows / Microsoft Windows

In 1995, Microsoft released Windows 95, which soon became the most widely-used operating system in the world. Autoconf and Libtool were written to support portability across Unix variants, but they provided a framework to support portability to Windows as well. This made it possible for a program to support both Unix and Windows from a single source code base.

Microsoft 的 Windows 95 在 1995 年上市後，很快的變成世界上被廣泛使用的作業系統。 Autoconf 與 Libtool 除了提供在各種 Unix 分支版本的可攜性支援外，也提供了延伸可攜性支援到 Windows 上的程式設計框架，這使得透過單一份原始碼來同時支援 Unix 與 Windows 成為可能的事情。

The key requirement of both Autoconf and Libtool was the Unix shell. The GNU bash shell was ported to Windows as part of the Cygwin project, which was originally written by Steve Chamberlain. The Cygwin project implements the basic Unix API in Windows, making it possible to port Unix programs directly.

Autoconf 與 Libtool 都需要 Unix shell 程式，而 GNU bash shell 恰被作為 Cygwin 計畫的一部分移植到 Windows 上。 Cygwin 計畫是由 Steve Chamberlain 所發起的，這個計畫在 Windows 上實做了基本的 Unix API ，使得 Unix 程式可以直接的移植到 Windows 上。

Once the shell and the Unix make program (also provided by Cygwin) were available, it was possible to make Autoconf and Libtool support Windows directly, using either the Cygwin interface or the Visual C++ tools from Microsoft. This involved handling details like the different file extensions used by the different systems, as well as yet another set of shared library features. This first version of this work was by Ian Lance Taylor in 1998. Automake has also been ported to Windows. It requires Perl to be installed (see section A.1 Prerequisite tools).

在 shell 與 Unix 的 make 程式都被移植到 Windows 上之後，便可以讓 Autoconf 與 Libtool 透過 Cygwin 或是 Microsoft Visual C++ toolkit 直接的支援 Windows。增加 Windows 支援牽涉到處理一些在不同的作業系統上細節，例如處理不同的檔案延伸名稱以及額外的共享函式庫功能，第一個可以支援 Windows 的版本在 1998 年由 Ian Lance 所開發。除此之外 Automake 也被移植到 Windows 上，他需要 Perl 預先安裝在系統上 (參見 A.1 需預先安裝的工具) 。

Libtool 的發展

2.5 Libtool Development / Libtool 的發展

Over time, Unix systems added support for shared libraries.

隨著時間的推移，Unix 系統加入了共享函式庫的支援。

Conventional libraries, or static libraries, are linked into a program image. This means that each program which uses a static library includes some or all of the library in the program binary on disk.

傳統的函式庫，或稱為靜態函式庫，會直接連結到程式檔之中。這表示，每個使用靜態函式庫的程式，會把所使用的函式庫的部份或全部複製到位於磁碟上的程式機械碼檔案之中。

Shared libraries, on the other hand, are a separate file. A program which uses a shared library does not include a copy of the library; it only includes the name of the library. Many programs can use a single shared library.

另一方面，共享函式庫則是分離的檔案。使用了共享函式庫的程式不需把函式庫的內容複製到程式內部；僅需在程式檔案內記錄函式庫的名字。數個程式可以使用一個共享函示庫。

Using a shared library reduces disk space requirements. Since the system can generally share a single executable instance of the shared library among many programs, it also reduces swap space requirements at run time. 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 which use the library to be rebuilt.

使用共享函式庫可以減少磁碟空間的使用需求。此外，在執行時系統可以讓多個程式共用一份共享函式庫的執行實體，因此也可以減少執行時期所需的記憶體分頁暫存空間需求。另外一個好處是，修正函式庫的臭蟲只需更新一份共享函式庫的檔案，而不需重新建置所有有用到函式庫的程式。

The first Unix shared library implementation was in System V release 3 from AT&T. The idea was rapidly adopted by other Unix vendors, appearing in SunOS, HP-UX, AIX, and Digital Unix among others. Unfortunately, each implementation differed in the creation and use of shared libraries and in the specific features which were supported.

第一個 Unix 的共享函式庫實作是在 AT&T 的 System V release 3 之中。這個概念很快的被其他 Unix 廠商採用，在 SunOS, HP-UX, AIX, 與 Digital Unix 等等都可以見到。遺憾的是，每個實作在函式庫的建立、使用與所支援的功能上都有些許的不同。

Naturally, packages distributed as source code which included libraries wanted to be able to build their own shared libraries. Several different implementations were written in the Autoconf/Automake framework.

很自然的，含有函式庫的原始碼套件會需要建置他們自己的共享函式庫。在 Autoconf/Automake 程式設計框架下，有好幾個不同的實作被撰寫出來。

In 1996, Gordon Matzigkeit began work on a package known as Libtool. Libtool is a collection of shell scripts which handle the differences between shared library generation and use on different systems. It is closely tied to Automake, although it is possible to use it independently.

在 1996 年，Gordon Matzigkeit 開始製作一個稱為 Libtool 的套件。 Libtool 是一組 shell 指令稿，用來應付在不同系統上產生與使用共享函式庫的差異。 Libtool 是針對 Automake 而製作的，但也可以被獨立的使用。

Over time, Libtool has been enhanced to support more Unix variants and to provide an interface for standardizing shared library features.

隨著時間的推移，Libtool 現在可以支援比剛發表時更多的 Unix 衍伸系統，並且也提供了一個標準化的界面來操作共享函式庫。

Automake 的發展

2.4 Automake Development / Automake 的發展

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 in order to use it. The `configure' script generated by autoconf would transform the `Makefile.in' file into a `Makefile' used by the make program.

在 1994 年時，對於處理各 Unix 分支版本間的差異，Autoconf 已能提供一個完整並可靠的程式設計框架。然而，為了使用 Autoconf，程式設計師得寫幾個巨大的 `Makefile.in' 檔案。由 autoconf 產生出的 `configure' 指令稿會把 `Makefile.in' 轉換成給 make 程式使用的 `Makefile' 檔案。

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.

程式設計師得在 `Makefile.in' 中描述建置程式的方法。在 Imake 中，類似的工作由 `Imakefile' 擔當，但在 `Imakefile' 中只需要列出建置程式所需要的原始碼檔案。當 Imake 產生 `Makefile' 時，他會自動將所需的程式建置規則加進去。在比較晚近的 BSD make 中，也內含有建置程式用的建置規則。

Since 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.

由於大部分的程式建置方法都一樣，因此在 `Makefile.in' 中有不少的內容是重複的。此外，GNU 計畫發展出了一組規範撰寫 `Makefile' 應依循的標準，這個標準相當的複雜，很容易把一些細節搞錯。

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.

這些種種不便開啟了 Automake 的發展，如同 autoconf 一樣，automake 也是給程式設計師使用的工具。程式設計師先用一套比一般的 `Makefile' 還精簡的語法撰寫 `Makefile.am' 檔案，接著執行 automake 來讀取 `Makefile.am' 並依據其內容產生 `Makefile.in' 檔。如此一來，所產生出來的 `Makefile.in' 檔便可以交給 autoconf 產生的指令稿來產生出 `Makefile' 檔案。

As with Imake and BSD make, the `Makefile.am' file need only 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.

就像 Imake 與 BSD make 一樣，在 `Makefile.am' 中只需要描述有哪些原始碼檔案會用來建置程式。在產生 `Makefile.in' 檔時 automake 會自動加入必要的規則，此外，automake 也會加入在 GNU 的 `Makefile' 標準中所要求的規則。

The first version of Automake was written by David MacKenzie in 1994. It was completely rewritten in 1995 by Tom Tromey.

第一版的 Automake 是 David MacKenzie 在 1994 年所撰寫。並在 1995 年，由 Tom Tromey 重新撰寫。

Configure 的發展

2.3 Configure Development / Configure 的發展

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 which 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, it was not something which package users could easily do themselves.

Cygnus 的 `configure' 指令稿與 GCC 原始的 `configure' 指令稿都必須針對所支援的 Unix 衍生作業系統做出修改，這代表當新的 Unix 衍生作業系統出現時，使用了這兩樣工具的軟體套件必須修改才能用在新的作業系統上。對於軟體的發展者而言，修改軟體套件以支援新的作業系統可能並非難事；但是對於軟體套件的使用者而言，這就不是件容易自己搞定的事情。

The same was true of Imake as it was commonly used. While it was possible for a user to build and configure Imake for a particular system, it was not commonly done. In practice, packages such as the X window system which use Imake are shipped with configuration information detailed for specific Unix variants.

被漸漸廣泛使用的 Imake 也面臨一樣的問題，雖然使用者自己針對特定系統建置並設定 Imake 不是難到不可能的事，但其實很少使用者這麼做。在實務上，像 X window 這類使用 Imake 的軟體套件，會帶有針對各個不同的 Unix 衍生作業系統所撰寫的配置檔。

Because Metaconfig and Autoconf used feature tests, the scripts they generated were often able to 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.

因為 Metaconfig 與 Autoconf 是利用一序列的測試來決定系統提供的功能，因此所產生的組態指令稿通常不用修改就能在新的 Unix 衍生作業系統上正確執行。這樣的特性讓這兩項工具被視為具彈性且不用頻繁維護的方案，並使 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.

在 1994 年 David MacKenzie 將 Autoconf 加以擴充，納入了 Cygnus 的 `configure' 指令稿與原始的 GCC `configure' 指令稿的功能。這次擴充使 Autoconf 支援針對不同系統使用不同的標頭檔或 makefile 檔案片段，另外也支援了跨平臺編譯。

GCC has since been converted to use Autoconf, eliminating the GCC `configure' script. Most programs which use the Cygnus `configure' script have also been converted, and no new programs are being written to use the Cygnus `configure' script.

從此之後，GCC 便轉而使用 Autoconf 並揚棄了原本的 GCC `configure' 指令稿。大多數使用 Cygnus `configure' 指令稿的程式也改用 Autoconf，新的程式也不再使用 Cygnus `configure' 指令稿。

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.

Metaconfig 在今日仍被用在 Perl 與幾個其他程式的建置中進行組態工作，Imake 也仍被用來組態 X window 系統。但是，在新的軟體套件中就很少會去使用這些工具了。

最初的 configure 程式

2.2 The First Configure Programs / 最初的 configure 程式

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

為了增進原始碼的可攜性，在 1992 年有四個不同的解決方案被開發出來:

• The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael Manfredi.

  Metaconfig ，由 Larry Wall 、 Harlan Stenn 以及 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.

  K. Richard Pixley 為 Cygnus 發展的 `configure' 指令稿；以及由 Richard Stallman 當初為 GCC 撰寫的 `configure' 指令稿， GCC 是 GNU Compiler Collection 的縮寫，其前身為 GNU C compiler 。這兩個指令稿非常相似，兩位發展者也經常交換意見。

• The GNU Autoconf package, by David MacKenzie.

  GNU Autoconf ， David MacKenzie 所發展。

• Imake, part of the X Window system.

  Imake ，屬於 X Window 的一部份。

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 would generate `Makefile's, and perhaps other files, which would then be used during the build step.

這些解決方案都把建置程式的過程分為兩個步驟: 組態，以及建置。在所有系統上，建置的程序會由 make 這個標準的 Unix 程式進行。 make 程式會由一個稱為 `Makefile' 的描述檔中讀取建置規則，並依據這些規則編譯程式。在建置作業前的組態階段，則會產生建置所需的 `Makefile' 以及其他建置時所需的檔案。

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.

Metaconfig 與 Autoconf 都透過執行一序列的測試程式來決定系統的功能與能提供的工具，這兩個工具的測試程式都是用 Bourne shell 指令稿所撰寫的。 (幾乎所有由 Unix 所衍生的作業系統都某種程度的支援 Bourne shell)

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.

Cygnus 的 `configure' 指令稿以及 GCC 原始的 `configure' 指令稿也是使用 Bourne shell 指令稿所撰寫的， Cygnus 與 GCC 針對不同的系統平台分別提供了一組特定的系統組態檔、標頭檔、以及指引編譯流程的 `Makefile' 描述檔。在早期的版本，要建置軟體的使用者必須告訴 `configure' 指令稿建置出來的程式的目標執行平台是什麼；後來 Per Bothner 修改了 `configure' 指令稿，讓 `configure' 可以自己利用 uname 這個標準的 Unix 程式以及其他系統環境的資訊來決定目標執行平台。

Imake is a portable C program. Imake can be customized for a particular system, and run as part of building a package. However, it is more normally distributed with a package, including all the configuration information needed for supported systems.

Imake 是一個用 C 語言所撰寫的程式，他具有高度的可攜性。 Imake 可以針對特定作業系統客制化，並在爾後建置軟體套件時使用。不過，通常 Imake 會與軟體套件一起被散佈，套件檔案中會附上在套件所支援的系統上建置軟體所需的組態資訊。

Metaconfig and Autoconf are programs used by program authors. They produce a shell script which is distributed with the program's source code. A user who wants to build the program runs the shell script in order to configure the source code for the particular system on which it is to be built.

Metaconfig 與 Autoconf 是給程式設計師使用的工具，兩者都會產生出隨著軟體原始碼散佈用的 shell 指令稿。要建置軟體的使用者可以執行由 Metaconfig 或是 Autoconf 產生的 shell 指令稿，以將程式原始碼針對執行建置作業的系統環境作調整。

The Cygnus and GCC `configure' scripts, and imake, do not have this clear distinction between use by the developer and use by the user.

Cygnus 與 GCC 的 `configure' 指令稿，以及 Imake ，就比較沒有如此的清楚區分說哪部份要由程式設計師使用，哪個部份是給建置套件的使用者使用。

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.

Cygnus 與 GCC 的 `configure' 指令稿支援了跨平台程式發展的功能，兩者都支援建置 cross-compiler ，或是利用 cross-compiler 建置程式。利用 cross-compiler ，可以編譯出執行在與編譯器執行平台相異的作業平台的機械碼。

Autoconf, Metaconfig and Imake did not have these features (they were later added to Autoconf); they only worked for building a program on the system on which it was to run.

Autoconf 、 Metaconfig 與 Imake 都不支援這些跨平台程式發展功能 (不過後來 Autoconf 有加入了這些功能) ；這些工具只能用來建置在建置環境中執行的程式。

The scripts generated by Metaconfig are interactive by default: they ask questions of the user 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.

由 Metaconfig 所產生出來的指令稿，在預設下是需要與使用者互動的: 在建置過程中，指令稿會問使用者一些問題。這個設計是為了取得一些比較難以自動偵測的系統組態與特性，比如說 setuid 程式的行為模式。

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 which can not be tested for, or sometimes requires the user to edit a header file after the `configure' script has run.

Cygnus 與 GCC 的 `configure' 指令稿、由 Autoconf 所產生的指令稿、以及 Imake 等這三者則相反，他們執行時不與使用者互動: 這些工具會自己做出所有關於環境特性的決定。如果要取得無法利用測試偵測出來的系統組態或特性，一般而言，套件發展者會撰寫額外的指令稿讓使用者可以利用指令列參數告知系統組態，或是，有時候可能會要求使用者在執行完 `configure' 指令稿後編輯一個特定的標頭檔，好指出系統的組態。

Unix 系統間的歧異

2.1 The Diversity of Unix Systems / Unix 系統間的歧異

Of the programs discussed in this book, the first to be developed was Autoconf. Its development was determined by the history of the Unix operating system.

在本書所討論的工具程式中，第一個被發展出來的工具是 Autoconf ，這個工具的發展與 Unix 作業系統的歷史習習相關。

The first version of Unix was written by Dennis Ritchie and Ken Thompson at Bell Labs 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.

第一版的 Unix 是在 1969 年由 Dennis Ritchie 與 Ken Thompson 在 Bell Labs 所寫出來的。在 1970 年代，雖然 Bell Labs 的母公司並未將 Unix 商業化販售，但是 Bell Labs 還是有將 Unix 以相對低廉的價格散佈到大學校園內。加州大學柏克萊分校的研究人員將他們的研究成果加入了 Unix 的原始碼中，這個增強後的版本就是後來為眾人所知的 BSD 版 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.

在 1980 年前期 AT&T 開始商業販售 Unix 作業系統，第一個 AT&T 的 Unix 版本稱為 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.

Unix 在 1980 年代開始普及，許多其他的公司也修改了 Unix 的原始碼並衍伸出自己的作業系統。比如，昇陽電腦的 SunOS ，迪吉多電腦的 Ultrix，以及惠普電腦的 HP-UX 。

Although all of the Unix variants were fundamentally similar, there were various differences 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.

雖然所有由 Unix 衍伸出的作業系統在設計上的出發點是相似的，但仍有相當的相異。他們有不同的標頭檔，系統函式庫所提供的函式呼叫也不太一樣，在終端機的控制以及工作的管理上也有可觀的差異。

The emerging POSIX standards helped to eliminate some of these differences. However, in some areas POSIX introduced new features, leading to more variants. Also, different systems adopted the POSIX standard at different times, leading to further disparities.

雖然 POSIX 標準的推出協助消弭了一些歧異，但是，因為 POSIX 也提出了一些新的功能，所以 POSIX 也引出了更多歧異。此外，隨著 POSIX 的改版，新舊版本的標準間也存在著差異，連帶使得不同時期推出的作業系統也因為採用了不同版本的標準而有歧異。

All of 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.

當以原始碼形式散佈程式時，這些作業系統間的歧異會造成困擾。就算是 memcpy 這類基本的函式也不見得在所有平台上都支援；比如說，在 BSD 的系統函式庫中，提供這項功能的是叫做 bcopy 的函式，不過他的參數順序與 memcpy 是正好顛倒的。

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.

如果程式設計師想讓程式能在各種由 Unix 衍伸出的系統上運作，他就得對各家衍伸系統間的差異非常了解。另外，作業系統可能為了符合 POSIX 標準或是引入新的功能而改版，進而造成版本間的歧異，這也是程式設計師得面對的問題。

While 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.

一般來講可以用 #ifdef 來辨認出平台所採用的作業系統與版本，但是，，要知道哪個版本有什麼功能則是越來越不容易。因此，程式設計師們漸漸明確的知道，需要一個系統化的方法來處理不同 Unix 衍伸系統間的差異。

發展歷史

2. History / 發展歷史

In this chapter we provide a brief history of the tools described in this book. You don't need to know this history in order to use the tools. However, 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 like this, it's only fair for us to credit the original authors and sources of inspiration, and to explain what they did.

在這一章，我們會簡單的描述一下本書主角 Autotools 的發展歷史。你不需要知道這些歷史就可以將這些工具上手，但是，了解這些工具程式的發展歷史可以幫助你理解為什麼這些工具的行為是今日你所見的這樣。此外，本書也要藉此機會向這些工具程式的創造者與貢獻者致敬，並解釋他們當初作下的設計決策背後的原因。

本書的組織方式

1.4 How this book is organized / 本書的組織方式

Like any good tutorial, this book starts with an explanation of simple concepts and builds on these fundamentals to progress to advanced topics.

如同所有優秀的入門文件一樣，這本書從簡單的概念開始，然後以這些簡單的概念為基礎，擴充到較複雜的主題上。

Part I of the book provides a history of the development of these tools and why they exist.

這本書的第一部份描述這些工具軟體的發展歷史，以及他們被發展出來的原因。

Part II contains most of the book's content, starting with an introduction to concepts such as `Makefile's and configuration triplets. Later chapters introduce each tool and how to manage projects of varying sizes using the tools in concert. Programs written in C and C++ can be non-portable if written carelessly. Chapters 14 and 15 offer guidelines for writing portable programs in C and C++, respectively.

本書的第二部份包含了大部分的內容，首先從介紹概念開始，如 `Makefile' 以及 configuration triplet 等等。接下來的章節會分別介紹如何使用 Autotools 的工具，以及如何利用這些工具管理不同規模的專案。最後，在 14 與 15 章中將會介紹使用 C/C++ 撰寫程式時需要注意的可攜性議題，撰寫 C/C++ 程式時若不特別注意的話，很容易會寫出無法移植的程式。

Part III provides information that you are unlikely to find in any other documentation, that is based on extensive experience with the tools. It embodies chapters that treat some advanced, yet essential, concepts such as the m4 macro processor and how to write portable Bourne shell scripts. Chapter 23 outlines how to migrate an existing package to the GNU Autotools framework and will be of interest to many developers. One of the most mystifying aspects of using the GNU Autotools for building packages in a cross-compilation environment. This is de-mystified in Chapter 25.

一些在其他文件中比較難找到的資訊被放在第三部份中，這些內容是以大量的實務經驗為基礎而撰寫的。首先，一些較進階並且重要的主題會在這部份討論，比如 m4 巨集處理器以及撰寫具可攜性的 Bourne shell 指令稿的注意事項。在第 23 章會提到如何將現有的專案移到 GNU Autotools 框架中，這部份會是很多發展者有興趣的地方。在第 25 章會解釋如何在 cross-compilation 環境中使用 GNU Autotools 來管理專案。

這本書的目標讀者

1.3 Who should read this book / 這本書的目標讀者

Revealing the mystery around the GNU Autotools is likely to raise the interest of a wide audience of software developers, system administrators and technical managers.

本書旨在揭開 GNU Autotools 背後運作原理的神祕面紗，我們相信這將會引起不少的軟體發展者、系統管理員，以及技術經理的興趣。

Software developers, especially those involved with free software projects, will find it valuable to understand how to use these tools. The GNU Autotools are enjoying growing popularity in the free software community. Developers of in-house projects can reap the same benefits by using these tools.

對軟體發展者來說，特別是有參與自由軟體專案的發展者，他們將會發現了解如何使用 Autotools 是非常有用的。隨著加入自由軟體社群的發展者增加，使用 GNU Autotools 的發展者也日益增加。對於為私人機構或公司執行專案的發展者，他們也可以在他們的專案中使用 Autotools 並從中得到一些益處。

System administrators can benefit from a working knowledge of these tools -- a common task for system administrators is to compile and install packages which commonly use the GNU Autotools framework. Occasionally, a feature test may produce a false result, leading to a compilation error or a misbehaving program. Some hacking is usually sufficient to get the package to compile, but knowing the correct way to fix the problem can assist the package maintainer.

系統管理員也可以從了解這些工具如何運作中得到益處 -- 有很多的軟體套件使用了 Autotools 作為建置框架，而編譯與安裝軟體套件恰巧是系統管理員經常要進行的工作。有時候，進行作業環境偵測時會發生錯誤，並導致編譯失敗，或是程式的不正常運作。雖然一些鋸箭療法般的處置通常已足以讓軟體正常編譯，但是了解正確的修正方式可以幫助套件的維護者在上游直接修復套件中的錯誤。

Finally, technical managers may find the discussion to be an insight into the complex nature of software portability and the process of building a large project.

最後，本書對於軟體可攜性以及大型專案建置面臨的複雜問題的討論，也能讓技術經理從中得到一些心得。

這本書未涵蓋到的範圍

1.2 What the book is not / 這本書未涵蓋到的範圍

This book is not a definitive reference to Autoconf, Automake or Libtool. Attempting to do so would fill this book with information that is doomed to obsolescence. For instance, you will not find a description of every predefined macro provided by Autoconf. Instead, the book will attempt to help you understand any macro you encounter and, instead, influence how you approach software portability and package building. The GNU manual for each tool should be consulted as a reference.

這本書並不是 Autoconf, Automake 或 Libtool 的完整使用手冊，如果把所有功能都寫入這本書的話，那麼這本書將會充滿一些即將過時的資訊。換言之，你不會在這本書中找到所有 Autoconf 預先定義好的巨集，然而，這本書會試著協助你理解你所碰到的任何巨集，並指引你一個增進軟體可攜性的方向。當你需要這些工具的完整參考手冊時，可以參考各工具的 GNU 手冊。

This book briefly introduces pertinent concepts, but does not attempt to teach them comprehensively. You will find an introduction to writing `Makefile's and Bourne shell scripts, but you should consult other references to become familiar with these broader topics.

對於一些相關的工具，這本書會簡單的介紹他們的使用概念，但不會很詳細並完整的解釋他們。比如說，你可以在這本書中找到撰寫 `Makefile' 或是 Bourne shell 指令稿的初步介紹，但當你想要對這些主題更了解，你就得要閱讀其他專門討論這些工具的參考文件。

這本書所討論的範圍

1.1 What this book is / 這本書所討論的範圍

This book is a tutorial for Autoconf, Automake and Libtool, hereafter referred to as the GNU Autotools. The GNU manuals that accompany each tools adequately document each tool in isolation. Until now, there has not been a guide that has described how these tools work together.

這本書是 Autoconf, Automake 以及 Libtool 的入門書，這三個工具軟體在本書會以 GNU Autools 稱之。雖然這些工具的用法已經在隨附的 GNU 使用手冊中已充分的記載，但在手冊中這幾件工具是被分開討論的。直到本書撰寫前，都沒有一個使用指引描述這些工具要如何一起使用這些工具。

As these tools have evolved over the years, design decisions have been made by contributors who clearly understand the associated problems, but little documentation exists that captures why things are the way they are. By way of example, one might wonder why some Autoconf macros use shell constructs like:

隨著這些工具的發展，有很多了解所有關連問題的工程師做出設計決策，並貢獻出程式碼。然而，卻只有很少量的文件描述這些設計決策的來龍去脈。比如說，可能有人會好奇，為什麼有些 Autoconf 的巨集使用下面的 shell script 寫法:

if test "x$var" = xbar; then echo yes 1>&5 fi

instead of the simpler:

而不用較精簡的:

if [ $var = bar ]; then echo yes 1>&5 fi

Much of this reasoning is recorded in this book.

有很多這類決策的來龍去脈，都記錄在這本書中。

序曲

1. Introduction / 序曲

Autoconf, Automake and Libtool are packages for making your software more portable and to simplify building it--usually on someone else's system. Software portability and effective build systems are crucial aspects of modern software engineering practice. It is unlikely that a software project would be started today with the expectation that the software would run on only one platform. Hardware constraints may change the choice of platform, new customers with different kinds of systems may emerge or your vendor might introduce incompatible changes in newer versions of their operating system. In addition, tools that make building software easier and less error prone are valuable.

Autoconf, Automake 以及 Libtool 是用來讓你所開發的軟體能更具可攜性，且更容易在別人的電腦系統上編譯的工具套件。近年來，軟體的可攜性與有效率的編譯與建置系統在近代軟體工程實務上漸漸佔有重要的一席之地。因為種種原因，在現在很少有軟體開發專案會在開始時就決定只支援單一平台。比如說: 硬體的限制可能會影響平台的選擇，使用不同系統平台的客戶可能會出現，或是您的作業系統軟體供應商可能會做出與舊系統不相容的變更。除此之外，能夠簡化並減少軟體編譯建置之流程與錯誤的工具是相當有價值的。

Autoconf is a tool that makes your packages more portable by performing tests to discover system characteristics before the package is compiled. Your source code can then adapt to these differences.

Autoconf 是一個可以讓你的軟體更具可攜性的工具，他會在編譯前執行一序列測試程式找出系統所安裝軟體的狀況，你的程式碼可以據此在不同的系統之間調適。

Automake is a tool for generating `Makefile's--descriptions of what to build--that conform to a number of standards. Automake substantially simplifies the process of describing the organization of a package and performs additional functions such as dependency tracking between source files.

Automake 是一個用來產生 `Makefile' -- 指出有哪些東西要編譯或建置的描述檔 -- 的工具。利用 Automake 可以大幅的簡化描述要建置套件內容的流程，並且可以提供一些額外的功能，如: 原始碼間的相依性檢查等等。

Libtool is a command line interface to the compiler and linker that makes it easy to portably generate static and shared libraries, regardless of the platform it is running on.

Libtool 是一個包裝了編譯器與鏈結器的命令列程式，這個工具可以為你產生靜態連結或動態連結的函式庫，你完全不用在意進行建置作業的系統平台到底是哪個。

AB 試譯

之前就想譯看看，不過半途而廢了。主要是想說弄個好用的工具，不過寫工具實在是挺辛苦的，而且前置作業太多要做了。

這次主要是可能會用到，算是比較急吧！所以想到直接放在 Blog 上。向後相容的部份，會使用 xml:lang 以及 div-tag 來作。版本管理就比較沒辦法了，只能以後再看看，剛好這本書已經差不多 freeze 了，所以這相對不是太大的問題。

樣式方面，會用 overflow: scroll; white-space: pre; 來處理 code 的呈現。

---

1. Introduction / 序曲
   1. What this book is / 這本書所討論的範圍
   2. What the book is not / 這本書未涵蓋到的範圍
   3. Who should read this book / 這本書的目標讀者
   4. How this book is organized / 本書的組織方式
2. History / 發展歷史
   1. The Diversity of Unix Systems / Unix 系統間的歧異
   2. The First Configure Programs / 最初的 configure 程式
   3. Configure Development / Configure 的發展
   4. Automake Development / Automake 的發展
   5. Libtool Development / Libtool 的發展
   6. Microsoft Windows / Microsoft Windows
3. How to run configure and make / 如何執行 configure 與 make
   1. Configuring / 進行組態
   2. Files generated by configure / 由 configure 所產生的檔案
   3. The most useful Makefile targets / 常用的 Makefile 建置目標