目錄
1 介紹
2 歷史
3 如何運行configure和make
4 Makefile介紹
5 一個最小的GNU Autotools項目
6 寫configure.in
7 GNU Automake介紹
8 啓動
9 一個小型GNU Autotools項目
10 GNU Libtool介紹
11 使用GNU Libtooll和configure.in，Makefile.am
12 一個大型的GNU Autotools項目
13 分發軟件包
14 安裝和卸載被配置的包
15 編寫和GNU Autotools可移植的C
16 編寫和GNU Autotools可移植的C++
17 動態加載
18 使用GNU libltdl
19 高級GNU Automake用法
20 一個複雜的GNU Autotools項目
21 M4
22 編寫可移植的Bourne Shell
23 編寫Autoconf的新宏
24 移植現有的庫到GNU Autotools
25 在Cygnus Cygwin中使用Autotools
26 和GNU Autotools交叉編譯
A 安裝GNU Autotools
B 平臺
C 生成文件依賴關係
D Autoconf宏參考
E OPL
索引
這是linuxsee第一次轉載別人的文章，只因今天在網上找autobook的中文版，竟找不到，且發現很多人和我遇到同樣的問題。於是決定將此 書翻譯，以滿足廣大linux 初學者學習automake的願望。已有人將前幾章譯過，在此發揚不重複勞動精神借用之，不久就會將autobook完整翻譯。因本人水平有限，難免有出 錯之處，還望各位不吝賜教，若有能力者強烈建議讀原文，在此下載。
——-本篇爲轉載內容，原作者文章請看這裏 ——–
1. 簡介
Autoconf、Automake 和 Libtool 這三個軟件包可以讓你的軟件具有更好的可移植性並簡化其構建的過程──尤其是在其他人的系統上。軟件的可移植性和高效的構建系統是現代軟件工程實踐中非常 重要的方面。現在，人們通常都希望軟件能在不止一個平臺上運行，因爲硬件的限制有可能會改變對平臺的選擇，新的客戶可能在使用不同的系統，而你所使用的操 作系統提供商也可能在新版本中引入與之前不兼容的變化。此外，能夠讓軟件構建過程更簡單且不容易出錯的工作也是非常有價值的。
Autoconf 這個工具可以在編譯軟件包前執行一系列測試，發現系統的特性，而你的源碼可以去適應不同系統的差別。通過這種方式，可以讓你的軟件包具有更好的可移植性。
Automake 是產生’Makefile’──描述要構建什麼──的工具，它遵從了很多的標準。Automake 極大地簡化了描述軟件包結構及追蹤源碼間依賴關係的過程。
Libtool 是編譯器和連接器的命令行接口，利用它可以方便地產生具有可移植性的靜態庫和動態鏈接庫。
1.1 本書涉及什麼
本書是關於 Autoconf、Automake 和 Libtool 的教程，以下將它們簡稱爲 GNU Autotools。GNU手冊分別對這三種工具進行詳細的闡述，但迄今爲止，還沒有哪本指南描述過它們如何共同工作的。
近年來，這些工具得到了發展，對相關問題很瞭解的貢獻者們做出了相應的設計，但是描述原理的文件卻幾乎沒有。在閱讀例子時，可能有人會問爲什麼 Autoconf 的宏使用以下的 shell 結構：
if test "x$var" = xbar; then |
而不是更簡單的
if [ $var = bar ]; then |
諸如此類問題的答案都記錄在了本書中。
1.2 本書不涉及什麼
本書不是一本 Autoconf、Automake 或 Libtool 的權威參考，否則書中將充斥過時的信息。譬如本書並不對由 Autoconf 提供的每一個預先定義的宏進行描述。相反，本書將幫助你理解你所遇到的任何宏，並影響你處理軟件可移植性和軟件包創建的方式。以上工具的GNU手冊可以作 爲參考書。
本書對相關概念只作簡單介紹而不是詳細地解釋它們。本書會介紹如何編寫’Makefile’和 Bourne shell 腳本，但是你必須參考其他工具書以便熟悉這些主題。
1.3 本書爲誰而作
軟件開發者，系統管理員和技術管理員很可能對關於 GNU Autotools 的書感興趣。
軟件開發者，特別是自由項目的開發者會認爲了解如何使用這些工具是十分有價值的，因爲 GNU Autotools 在自由軟件社區中正變得越來越流行。室內項目的開發者如用這些工具也會受益非淺。
系統管理者能從這些工具的使用知識中受益。因爲系統管理員的通常任務就是編譯和安裝使用 GNU Autotools 框架的軟件包。偶爾，特性測試也會產生錯誤的結果而導致編譯錯誤或程序異常。通常稍微 hacking 一下就可以編譯軟件包了，但是知道解決問題的正確方法能夠幫助軟件包的維護者。
最後，書中的討論將使技術管理員對軟件可移植性的複雜本質和創建大型項目的過程有進一步的瞭解。
1.4 本書是如何組織的
與任何一本好的教程一樣，本書首先解釋簡單的概念，然後在這些基礎知識上再進一步延伸至高層次的主題。
本書的第一部分將闡述這些工具的發展及其存在的原因。
第二部分則是本書的主要內容。首先解釋’Makefile’和 configuration triplets 之類的概念。此後的章節將逐一介紹各個工具及如何使用它們來處理不同規模的項目。如果用 C和 C++ 語言編寫的程序十分粗糙的話，該程序將不可移植。第 14 和 15 章將分別指導如何用 C 和 C++ 語言編寫可移植程序。
第三部分提供的信息是你在其他任何參考書中都沒法找到的。因爲該部分是根據大量應用這些工具的實際經驗編寫而成的。其中有章節是關於一些高級但又十 分重要的概念，如m4宏處理器及如何寫可移植 Bourne shell 的腳本。第 23 章將概述如何把一個現存的軟件包移植到 GNU Autotools 框架。許多開發者會對該章內容十分感興趣，因爲在交叉編譯環境中使用 GNU Autotools 創建軟件包是最令人困惑的。第 25 章將就此作出解釋。
2. 歷史
本章我們就書中工具的發展歷史進行簡要闡述。你不必爲了使用這些工具而去了解歷史，但是瞭解這些工具的發展過程將有助於瞭解爲何它們以目前的方式運作。此外，在這樣一本書中，我們有必要感謝原創作者及其靈感來源，並對他們所做的貢獻作一番解釋。
2.1 Unix 的多樣性
在數種所討論的程序中，最早開發出來的是 Autoconf。它的發展是由 Unix 操作系統的歷史決定的。
貝爾實驗室的 Dennis Ritchie 和 Ken Thompson 於 1969 編寫了最早版本的 Unix。在上世紀七十年代，儘管貝爾實驗室並不被允許商業化地出售 Unix，但是它確實以較低的價格將 Unix 賣給了一些大學。加州大學伯克利分校在原 Unix 的源碼上做了改進，並形成了 BSD 版的 Unix。
上世紀八十年代早期，AT&T 簽定允許他們商業化地出售 Unix 的協議，Unix 的第一個 AT&T 版本是 System III。
八十年代隨着 Unix 越來越流行，其他一些公司對原有的 Unix 進行修改而形成了他們自己的版本。例如，Sun Microsystems 的 SunOS、Digital Equipment Corporation 的 Ultrix 以及 Hewlett Packard 的 HP-UX。
儘管 Unix 的各個版本在本質上是相似的，各版本之間還是有區別的。它們的頭文件集和系統庫所提供的函數還是有些細微的差別，而在中斷處理和作業控制等方面存在的差別則更大。
然而 POSIX 的出現則消除了其中的一些差別。但是 POSIX 在一些領域中又引入了新的特性，從而導致了更多的版本。同樣，不同系統採用不同時期的 POSIX 標準，也導致了更多的差異。
所有這些差異給作爲源代碼散佈的程序帶來了問題。即便是像 memcpy 這樣簡單的函數也不是任何系統都提供的；BSD 系統庫提供與之類似的功能 bcopy，但是參數的次序是相反的。
要想使程序在不同版本的 Unix 都能運行，程序的作者若就必須熟悉各版本之間的具體差別。他們還需要注意這些差別在各版本中是如何體現的，因爲它們雖然都遵循 POSIX 標準，但是各自又引入了新的各不相同的特性。
雖然通常情況下可以用 #ifdef 來確認特定的系統和版本，但是人們越來越難以知道哪個版本具有哪些特性。因此，人們需要更系統的方法來處理不同版本間的差異。
2.2 第一個配置程序
到 1992 爲止，人們已經開發了四個系統來幫助實現源代碼的移植：
- Metaconfig program，作者是 Larry Wall、Harlan Stenn 和 Raphael Manfredi。
- Cygnus’configure’腳本，作者是 K. Richard Pixley，以及原由的 GCC’configure’腳本，作者是 Richard Stallman。兩者十分相似，且其開發者經常交流。GCC 是 GNU Compiler Collection, 也就是以前的 GNU C 編譯器。
- GNU Autoconf 軟件包，作者是 David MacKenzie。
- Imake，X Window 系統的一部分
以上系統都將構建程序分成兩步：配置和構建。並且在進行構建時都使用了標準的 Unix make 程序。Make 程序從’Makefile’中讀取一系列規則，並用這些規則創建程序。配置步驟所做的工作是產生’Makefile’文件，也可能還產生其它可能在構建過 程中使用到的文件。
Metaconfig 和 Autoconf 都用特性測試來測試系統的兼容性。它們用 Bourne shell 腳本（所有 Unix 版本都以不同形式支持 Bourne shell 腳本）運行不同的測試以確定系統支持的內容。
Cygnus 的’configure’腳本和原先的 GCC’configure’腳本也是 Bourne shell 腳本。它們靠小的配置文件得到每個系統的變量，包括頭文件和’Makefilse’片段。在早期版本中，編譯程序的使用者必須告訴腳本該程序是爲哪種系統 構造的；後來 Per Bothner 對其進行了改進，他編寫的 shell 腳本能根據標準 Unix uname 程序和其它信息確定系統類型。
Imake 是可移植的 C 程序。它可以被定製以用於特定的系統，並作爲軟件包構建的一部分來運行。但更常見的情況是，Imake 和軟件包一起發行，其中的軟件包包含了被支持的系統所需的所有配置信息。
Metaconfig 和 Autoconf 是程序作者使用的程序。它們產生的 shell 腳本將與程序的源代碼一起散佈。而想要構建程序的用戶在程序要運行的系統上執行這個 shell 腳本，從而爲源代碼產生相應系統的配置。
Cygnus 和 GCC’configure’腳本, 還有 imake, 對於用戶和開發人員使用來說沒有分別。
Cygnus 和 GCC’configure’腳本支持跨平臺開發,兩者都支持內建一個可以在不同的平臺上編譯的跨平臺的編譯器，用來編譯程序。
Autoconf, Metaconfig 和 Imake 沒有這些功能 (他們最後加入了 Autoconf)；它們只支持在它們各自工作的平臺上編譯程序。
TMetaconfig 生成的腳本是默認交互的: 它們在執行時向用戶詢問。這樣可以使它們知道難於測試出的平臺的特徵，來確定平臺下的執行方式。
Cygnus 和 GCC’configure’腳本,及autoconf生成的腳本, imake 程序不是交互式的: 它們自己決定任何事。 使用 Autoconf 時，包開發者一般會寫命令行的參數選項來決定它們不能檢測出的功能，有時會要求用戶在執行 ‘configure’ 腳本後寫一個頭文件。
2.3 配置的發展
Cygnus 的’configure’腳本和原先的 GCC’configure’腳本必須更新以適應它們支持的 Unix 新版本。也就是說，隨着 Unix 新版本的不時出現，使用它們的軟件包就時常處於過時狀態。儘管對開發者而言，增加新系統版本的支持並不困難，但是軟件包用戶卻不能輕易完成這項任務。
Imake 在通常的使用過程中也存在着同樣的問題。儘管用戶可以爲特定系統創建並配置 Imake，但是這種做法並不常用。事實上，像 X window 系統這樣使用 Imake 的軟件包是與針對特定 Unix 版本的詳細配置信息一起發佈的。
由於 Metaconfig 和 Autoconf 都使用特性測試，它們產生的腳本通常不用修改就能在新的 Unix 版本上運行。因此，它們更容易使用並且適應性更強，而 Autoconf 也被廣泛的應用。
1994年，David MacKenzie 將 Cygnus 的’configure’腳本和原先的 GCC’configure’腳本的特性融合到 Autoconf 中，其中包括使用針對特定系統的頭文件和 makefile 片段，還包括對交叉編譯的支持。
GCC 至此也改用 Autoconf 來替代 GCC’configure’腳本。使用 Cygnus’configure’腳本的程序也大多用 Autoconf 進行了改寫，人們也不再用 Cygnus 的’configure’腳本編寫新的程序了。
metaconfig 程序至今仍被用於配置 Perl 和其他很少的程序。imake 仍被用於配置 X window 系統。但是，這些工具一般不再用於新的軟件包。
2.4 Automake 的發展
到 1994 年，Autoconf 已經是處理不同 Unix 版本之間差異的固定框架。但是程序開發者仍不得不編寫龐大的’Makefile.in’文件才能使用 Autoconf。由 Autoconf 產生的’configure’腳本將’Makefile.in’文件轉化爲 make 程序使用的’Makefile’。
‘Makefile.in’文件必須對如何創建程序進行描述。而在 Imake 中具有’Makefile.in’功能的’Imakefile’卻只需描述創建程序時使用了哪些源文件。當 Imake 產生一個’Makefile’時，它會自動增加關於如何創建程序的規則。BSD make 程序後來的版本也包含了構建程序的規則。
由於大多程序的創建方式是相同的，’Makefile.in’文件中也存在大量的重複。同時，GNU 項目開發了一個相當複雜的’Makefile’標準集，它很容易產生細節錯誤。
上述因素都促成了 Automake 的開發。automake 像 autoconf一樣是由開發者運行的程序。開發者編寫名爲’Makefile.am’的文件；這些文件使用比普通的’Makefile.in’更簡單的 語法。Automake 讀取’Makefile.am’文件併產生’Makefile.in’文件。這樣，由 autoconf 產生的腳本將這些’Makefile.in’文件轉化爲’Makefile’。
如同 Imake 和 BSD make 一樣，’Makefile.am’文件只需描述用於構建程序的文件。Automake 在產生’Makefile.in’文件時會自動增加所需規則。automake 還會增加 GNU’Makefile’要求的任何規則。
1994 年，David MacKenzie 編寫了 Automake 的第一個版本。1995年，Tom Tromey 對此進行了徹底的改寫。
2.5 Libtool 的發展
隨着時間的發展，Unix 系統增加了對共享庫的支持。
傳統的庫，即靜態庫，是與程序的映象鏈接在一起的。也就是說，使用靜態庫每個程序中都包含了磁盤上部分或全部的庫。
共享庫是獨立的文件。使用共享庫的程序並不包含庫，它僅僅包含庫的名字。許多程序能使用同一個共享庫。
使用共享庫降低了對磁盤空間的需求。由於通常情況下系統能在許多程序中共享同一個共享庫的可執行實例，使用共享庫也降低了運行時對交換空間的需求。另外，通過更新磁盤上的一個共享庫文件就能改正錯誤，而不必重建使用庫的所有程序。
第一個 Unix 的共享庫應用是在 AT&T 發行的 System V 第三版。這一想法很快被其他的 Unix 銷售商採納。如 SunOS, HP-UX, AIX, 和 Digital Unix。不幸的是，各個共享庫在創建、使用以及它所支持的具體特徵方面都是不同的。
很自然地，包含庫並作爲源代碼散佈的軟件包想創建它們自己的共享庫。幾個不同的共享庫實現被寫在 Autoconf/Automake 框架上。
1996 年, Gordon Matzigkeit 開始創建軟件包 Libtool。Libtool 是 shell 腳本集合。這些 shell 腳本集合是用於處理不同版本的共享庫在不同系統中使用時的差異。Libtool 與 Automake 緊密相連，而且不能獨立使用。
隨着時間的推移，Libtool 已經能夠支持更多的 Unix 版本，並能提供使共享庫特性標準化的接口。
2.6 Microsoft Windows
1995 年，Microsoft 發行了 Windows 95。Windows 95 很快成爲全世界廣泛應用的操作系統。Autoconf 和 Libtool 在編寫時是爲了支持不同 Unix 版本之間的移植，但是它們提供的框架結構也能支持移植到 Windows。這樣使得程序可以支持來自同一源代碼庫的 Unix 和 Windows。
Autoconf 和 Libtool 中都必須需要使用 Unix shell。在由 Steve Chamberlain 編寫的 Cygwin 項目中，GNU bash shell 被移植到了 Windows 上。Cygwin 項目在 Windows 上實現了基本的 Unix API，這就使直接移植 Unix 程序成爲可能。
當 shell 和 Unix make 程序（也是由 Cygwin 提供的）可以使用後，Autoconf 和 Libtool 就可以通過使用 Cygwin 接口或 Microsoft 的 Visual C++ 直接支持 Windows 了。這需要處理像不同系統使用不同文件擴展名以及共享庫的另一特性集之類的細節。Ian Lance Taylor 於 1998 年第一次完成了這個任務。Automake 也被移植到 Windows上，它需要使用 Perl（see section Prerequisite tools）。