前言
本文根據《Autotools - A Practioner's Guide to GNU Autoconf, Automake, and Libtool》第一章翻譯整理，省略了部分語句。
正文
正如序言裡所講，GNU Autotools的目的是使得最終使用者的生活變得簡單，而不是維護者的。雖然如此，從長遠來看，作為一個工程管理者，使用Autotools會使你的工作變得簡單，盡管可能不是你所懷疑的理由。Autotools架構盡可能簡單，給出它所提供的功能。Autotools的真正目的是雙重的：它為你的使用者服務，并且使你的工程令人難以置信地可移植---甚至在你從沒測試過，安裝過或建構過你的代碼的系統上。
在這本書中，我會經常使用詞語Autotools的，雖然你在GNU歸檔中找不到使用這個詞的軟體包。我用這個詞表示下列三個GNU包，它們被社群認為是GNU編譯系統中的一部分
> Autoconf： 用于為工程産生配置腳本；
> Automake： 用于簡化建立一緻性和功能性Makefile的過程；
> Libtools： 用于為共享庫的可移植建立提供一個抽象；
其它建構工具，例如開源源碼包CMake和SCons，嘗試提供與Autotools相同功能的但是以一個更加使用者友善的方式。但是，這些工具試圖躲在圖形使用者界面和腳本建構者之後的功能，實際上最終使它們的功能變得較弱。
誰應該使用Autotools
如果你正在寫目标機是Unix或Linux的開源軟體，你應該絕對正使用GNU Autotools。即使是你在為Unix或Linux寫專有軟體，你将會極大地受益于它們。Autotools會提供你一個建構環境，允許你的工程成功地在你将來的版本或分支建構，使用幾乎沒有改變的建構腳本。這是有用的，甚至你隻是打算針對單一的Linux發行版，因為，說實話，你真的無法提前知道你的公司将來是否會希望你的軟體運作在其它平台上。
語言的選擇
在決定是否使用Autotools，你程式設計語言的選擇是另一個重要的因素。記住Autotools由GNU設計用于管理GNU工程。在GNU社群，有兩個因素決定一種計算機程式設計語言的重要性：
> 有沒有GNU包用這個語言編寫
> GNU編譯工具集是否支援這個語言
基于這兩個标準，Autotools為下列語言提供原生支援(由原生支援，我的意思是Autotools會在這些語言中編譯，連結，和運作源碼級特性檢查)：
> C
> C++
> Objective C
> Fortran
> Fortran 77
> Erlang
是以，如果你想建構一個Java包，你可以配置Automake來這麼做(如我們在第8和第9章所見)，但你不能要求Autoconf來編譯，連結，或運作基于Java的檢查，因為Autoconf根本就不原生地支援Java。然而，你可以找到Autoconf宏(在後續章節中，我将更為詳細地涉及)來提升Autoconf的能力，以管理用Java寫的工程的配置過程。
開源軟體開發者正積極地在gcj編譯器和工具集方面進行工作，是以一些原生Java支援可能最終會被添加到Autoconf。但是截至到編寫這本書時，gcj仍然有些不成熟，目前很少有GNU包用Java編寫，是以問題對于GNU社群來講仍然不是至關重要。
生成你的軟體包編譯系統
GNU Autotools架構包括三個主要的包：Autoconf，Automake，和Libtool。這些包中的工具可以産生依賴于實用軟體的代碼和來自gettext，m4，sed，make，和perl等其它包的功能。
對于Autotools，區分維護者的系統和最終使用者的系統是重要的。Autotools的設計目的指明，一個Autotools産生的編譯系統，應該緊緊依賴現成的并預先安裝在最終使用者機器上的工具。例如，維護者使用的機器建立一個分支需要Perl解釋器，但是一個最終使用者運作的機器從發行分支包建構産品并不需要Perl。
一個必然的結果是，最終使用者的機器不需要安裝Autotools，一個最終使用者的系統隻需要一個合理的符合POSIX标準版本的make和Bourne shell的一些變種，以執行産生的配置腳本。當然，任何包也會需要編譯器，連結器，和其它被項目維護者認為必要的工具來講原代碼檔案轉換成可執行二進制程式，幫助檔案和其它運作時資源。
如果你曾經下載下傳，建構和安裝來自tarball(一種以.tar.gz, .tgz, .tar.bz2或其它擴充的壓縮歸檔檔案)的軟體，毫無疑問你知道整體的過程。它通常看上去像這樣：
[cpp] view plain copy print ?
- $ gzip -cd hackers-delight-1.0.tar.gz | tar xvf -
- ...
- $ cd hackers-delight-1.0
- $ ./configure && make
- ...
- $ sudo make install
- ...
Autoconf
盡管配置腳本很長又很複雜，使用者隻需要在執行時指定一些變量。大多數變量是簡單的選擇，關于元件，特性，和選項，例如：編譯系統在哪裡可以找到庫和頭檔案？最終産品我想安裝在哪裡？我想把哪些可選的元件建構進我的産品？
Autoconf産生的配置腳本提供了一個通用的選項集，這對所有運作在POSIX系統上的可移植軟體項目都是重要的。這包括修改标準位置(一個我将在第2章中涉及的概念)的選項，也包括定義在configure.ac檔案的項目特定選項(我将在第3章中讨論)。
Autoconf包提供多個程式，包括下面的：
> autoconf
> autoheader
> autom4te
> autoreconf
> autoscan
> autoupdate
> ifnames
autoconf
autoconf是個簡單地Bourne shell腳本。它主要的功能是確定目前shell包含必要的功能來執行M4宏處理器(我将會在第3章讨論Autoconf的M4使用)。該腳本的剩餘部分解析指令行參數，并執行autom4te。
autoreconf
autoreconf工具執行每個工程所要求的autoconf，automake和libtool軟體包中的配置工具。autoreconf最大限度地減少報告時間戳，特性，和項目狀态變化的重生量。它被寫為試圖鞏固現有維護者編寫的，基于腳本的工具，以正确的順序運作所有需要的Autotools。你可以認為autoreconf是那種智能的Autotools引導工具。如果所有你有的是一個configure.ac檔案，你可以與運作autoreconf來執行所有你需要的工具，以正确的順序，進而使configure會被合适地生成。
autoheader
autoheader工具産生一種C/C++相容的頭檔案模闆，根據configure.ac裡面的多種結構。這個檔案通常被稱為config.h.in。當最終使用者執行configure，配置腳本根據config.h.in生成config.h。作為一個維護者，你将會使用autoheader來生成會包括在你的分支軟體包中的模闆檔案。(我們會在第3章中詳細研究autoheader)。
autoscan
autoscan程式為新的工程生成一個預設的configure.ac檔案；它也可以檢查一個存在的Autotools工程的缺陷和機會以作增強。(我們将會在第3章和第8章中詳細套路autoscan)。autoscan對于一個使用不是基于Autotools的編譯系統作為一個工程的起始點是非常有用的，但是它也可能在提示增強一個現有基于Autotools工程的功能也是有用的。
autoupdate
autoupdate工具用于更新configure.ac或模闆(.in)檔案，以比對目前Autotools版本所支援的文法。
ifnames
ifnames程式是一個在通常情況下并未充分使用的小工具，它可以接受指令行中的源檔案名清單，顯示stdout裝置上的C預處理器定義清單。這個工具被設計用于幫助維護者決定放入configure.ac和Makefile.am檔案中的内容，以使得它們可移植。如果你的工程考慮寫成某種程度上可移植，ifnames可以幫助你決定那些試圖可移植的部分在你源碼樹中的位置，給出潛在的可移植定義的名字。
autom4te
autom4te工具是一種為M4的智能緩存包裝器，被其它大多數Autotools工具所使用。autom4te緩存減少了相繼工具通路configure.ac的時間多達30%。我并不想花費太多時間在autom4te(發音automate)，因為它主要由内部的Autotools的使用。它工作的唯一标志是autom4te.cache目錄會在你工程的頂層目錄出現，在你運作autoconf或autoreconf之後。
攜手合作
前面所列的工作中，autoconf和autoheader是項目維護者在生成configure腳本時唯一會直接使用的，autoreconf是開發者唯一需要直接執行的。圖1-1顯示了輸入檔案和autoconf與autoheader互相作用，産生相應的産品檔案。
注意：在本書中我都會使用圖1-1中的資料流圖。黑色盒子代表Autotools軟體包；白色盒子自代表生成對象。方角盒子是腳本；圓角盒子是資料檔案。這裡大多數标簽的意義應該是明顯的，至少有一個需要解釋下：術語ac-vars是指Autoconf特定替換文本。很快我會解釋框滴漸變的aclocal.m4盒子。
這套工具的主要任務是生成一個配置腳本，可以用來配置一個工程建構目錄。這個腳本不會依賴Autotools它們自己；事實上，autoconf被設計為生成可以運作在所有類Unix平台和絕大多數Bourne shell變種上的配置腳本。這意味着你可以用autoconf生成一個配置腳本，然後可以在沒有安裝Autotools的機器上執行這個腳本。
autoconf和autoheader程式要麼直接由使用者執行，要麼由autoreconf間接執行。它們從你工程中的configure.ac檔案和多種符合Autoconf的M4宏定義檔案中擷取輸入，使用autom4te維護緩存資訊。autoconf生成一個叫configure的配置腳本，一種非常容易移植的Bourne shell腳本，使你的工程提供許多有用的配置能力。autoheader基于在configure.ac中的特定宏定義生成config.h.in模闆。
Automake
Automake的工作是将你項目建構過程的簡化規範轉換成樣闆Makefile文法，始終在第一時間正常工作，并提供所有期望的标準功能。Automake建立的工程支援在GNU編碼标準中定義的準則(在第2章中讨論)。
automake軟體包以Perl腳本的形式提供下列工具：
> automake
> aclocal
automake
automake程式根據高層次的生成規範檔案(稱為Makefile.am)生成标準makefile模闆(稱為Makefile.in)。這些Makefile.am輸入檔案基本上隻是正常的makefile。如果你在一個Makefile.am檔案中隻放入一些需要的Automake定義，你會得到一個包含幾百行的參數化的make腳本Makefile.in。
如果你添加make文法到一個Makefile.am檔案，Automake會将這個代碼移動到由此而來的Makefile.in檔案中功能上最正确的位置。實際上，你可以編寫你的Makefile.am檔案，因而所有包含的是普通的make腳本，由此生成的Makefile會很好的工作。這個直通功能給予你擴充Automake功能的能力，以适合你工程的特殊需求。
aclocal
在GNU Automake手冊中，aclocal工具被記載為一種臨時變通，為Autoconf的某種靈活性的缺乏。Automake擴充了Autoconf，通過添加一個宏擴充集，但是Autoconf設計時真沒有考慮這種層次的擴充。
添加使用者定義宏到一個Autoconf工程的最初記載方法是建立一個叫aclocal.m4的宏，把使用者定義宏放在這個檔案中，将此檔案放在configure.ac相同的目錄。Autoconf然後在處理configure.ac時，自動的包括這個宏檔案。Automake的設計者發現這個擴充機制太有用了讓人欲罷不能；然而，使用者會被要求添加一個m4_include聲明到一個可能是不必要的aclocal.m4檔案中，為了包括Automake宏。由于這兩種使用者自定義的宏和M4本身被認為是先進的概念，這被認為是要求的話是過于苛刻的。
aclocal被設計用于解決這個問題---這個工具為工程生成一個aclocal.m4檔案，其中同時包含使用者定義宏和所有需要的Automake宏(Automake宏拷貝到這個檔案，但是寫在acinclude.m4中的使用者定義宏僅僅是在檔案結尾引用m4_include聲明)。項目維護者現在添加使用者定義宏到一個名為acinclude.m4的新檔案，而不是直接添加到aclocal.m4。
為了使讀者清楚Autoconf并不依賴Automake(也許因為有點固執)，GNU Autoconf手冊原來建議，在你添加Automake到一個存在的Autoconf工程時，将aclocal.m4重命名為acinclude.m4，這種方法仍然廣泛使用。aclocal的資料流在圖1-2中描述。
然而，Autoconf和Automake的最新文檔同時指出整個範式已經過時。開發者現在應該指定一個包含M4宏檔案集的目錄。目前的建議是在工程根檔案目錄下建立一個稱為m4的目錄，添加到裡面的宏作為單獨的.m4檔案。所有在此目錄裡的檔案在Autoconf處理configure.ac之前，将會被收集到aclocal.m4中。
現在應該更加清楚知道，為何在圖1-1中的aclocal.m4盒子不能決定它所應該的顔色。當你在不通過Automake和Libtool時使用它，你手寫aclocal.m4。然而，當你通過Automake使用它，這個檔案由aclocal工具生成，你在acinclude.m4或一個m4目錄中提供工程特定的宏。
Libtool
你如何在不同的Unix平台上建構共享庫，在不添加很多平台相關的條件代碼到你的編譯系統和源代碼？這個問題是libtool軟體包試圖解決的。
在類Unix平台上，有相當顯著的共同功能。然而，一個非常顯著且必須做的不同是，共享庫如何建構，命名和管理。有些平台命名它們的共享庫libname.so，其它平台使用libname.a，或甚至是libname.sl，任然存在其它甚至不提供本地共享庫。一些平台提供libdi.so來允許軟體在運作時動态加載和通路庫功能，然而其它還有提供不同機制的，一些平台完全不提供這種功能。
Libtool的開發者已經仔細考慮了所有這些差别。Libtool支援大量平台，不僅僅提供在makefile中隐藏庫命名差異的Automake宏集，也提供一個可添加到程式的動态加載程式功能的可選庫。這個功能允許維護者使它們的運作時和動态對象管理代碼更加可移植。
libtool軟體包提供下列程式，庫，和頭檔案：
> libtool (程式)
> libtoolize (程式)
> ltdl (靜态和動态庫)
> ltdl.h (頭檔案)
libtool
libtool軟體包附帶的libtool shell腳本，是libtoolize為項目生成的自定義腳本的一個通用版本。
libtoolize
libtoolize shell腳本準備你的項目來使用Libtool。它生成一個通用libtool腳本的自定義版本，添加到你的工程目錄。這個自定義腳本伴随着Automake生成的makefile附帶在工程中，在合适的時間在使用者系統上執行這個腳本。
ltdl, Libtool 的C語言 API
libtool軟體包也提供ltdl庫和相關的頭檔案，提供跨平台的一緻性運作時共享對象管理。ltdl庫可能會被靜态地或動态地連結進你的程式，給予它們平台之間的一緻性運作時共享庫通路接口。
圖1-3闡述了配置和建構工程的automake，libtool腳本和用于建立産品的輸入檔案之間的互相作用關系。
Automake和Libtool都是标準的可插拔選項，可用一些簡單的宏調用添加到configure.ac。
建構你的軟體包
作為維護者，你可能經常建構你的軟體包，并且你也很可能相當熟悉你工程裡的元件，架構和編譯系統。然而，你應該确定你的使用者的建構經驗比你自己的少多了。一種方式是，在建構你的軟體包時，給予你使用者一個簡單的，容易懂的方法來遵循。在下面的部分，我會給你展示由Autotools提供的建構方法。
運作configure
在運作Autotools後，留下了一個稱為configure的shell腳本和一個或多個Makefile.in檔案。這些檔案旨在附帶在你的項目釋出分發包中。你的使用者會下載下傳這些軟體包，解壓，和在項目的頂層目錄輸入./configure && make。然後，configure腳本會從由automake建立的Makefile.in模闆生成makefiles(稱為Makfile)，從由autoheader生成的config.h.in模闆生成一個config.h頭檔案。
Automake生成Makefile.in模闆而不是make檔案，是因為沒有make檔案，你的使用者無法運作make；你不希望它們在運作configure之前運作make，這一功能防止他們這麼做。Makefile.in模闆同你可能手寫的make檔案幾乎是相同的，除非你沒必要這麼做。它們也做了很多不僅僅是大多是人會手寫的代碼。另一個不附帶準備運作的make檔案的原因是，它給了configure機會來直接插入平台字元和使用者指定選項特性到make檔案。這使得它們更加适合目标平台和最終使用者建構偏好。
圖1-4闡述了configure和為建立make檔案和config.h頭檔案在配置過程所執行腳本之間的關系。
configure腳本和另一個稱為config.status腳本之間有一個雙向關系。你可能已認為configure腳本生成了你的make檔案。但事實上，除了一個日志檔案之外，configure唯一生成的檔案是config.status。
configure被設計為指定使用者系統上可用平台特點與特性，在configure.ac中所指定。一旦它具有這個資訊，它會生成config.status，後者包含所有的檢查結果，然後執行這個腳本。反過來，config.status腳本使用嵌入在裡面的核對資訊，生成平台特定的config.h和make檔案，以及任何在configure.ac中所指定的執行個體化資訊。
注意： 如圖1-4中雙向箭頭所示，config.status也可以調用configure。當我們使用--recheck選項，config.status會調用configure，使用原來用于生成config.status的相同的指令行選項。
configure腳本也會生成一個稱為config.log的日志檔案，當一個configure在使用者系統中執行失敗時，其中會包含非常有用的資訊。作為維護者，你可以用此資訊來調試。config.log也會記錄configure是如何被執行的。(你可以使用config.status --version來找到用于生成config.status的指令行選項。)這一特性可以是非常友善的，比如，當一個使用者從一個長假回來時，忘記了他原來用于生成工程建構目錄的選項。
注意：為了生成make檔案和config.h頭檔案，隻要在工程建構目錄中輸入./config.status。使用原本用于生成config.status檔案的選項來生成輸出檔案。
在源碼目錄外建構
Autotools建構環境的一個鮮為人知的功能是，在一個工程源碼樹裡面生成不是必須的。就是說，如果一個使用者從一個目錄執行configure，而不是工程源碼目錄，可以在一個孤立的建構目錄裡生成一個完全的建構環境。
在下面的例子中，使用者下載下傳doofabble-3.0.tar.gz，解壓，和建立兩個同級目錄，稱為doofabble-3.0.debug和doofabble-3.0.release。切換到doofabble-3.0.debug目錄，執行configure腳本，使用一個相對路徑，用一個doofabble特定調試選項，然後在同一目錄運作make。最後，切換到doofabble-3.0.release目錄，做相同的事，這一次，configure沒有使能調試選項。
[cpp] view plain copy print ?
- $ gzip -dc doofabble-3.0.tar.gz | tar zxf -
- $ mkdir doofabble-3.0.debug
- $ mkdir doofable-3.0.release
- $ cd doofabble-3.0.debug
- $ ../doofabble-3.0/configure --enable-debug
- ...
- $ make
- ...
- $ cd ../dofable-3.0.release
- $ ../doofabble-3.0/configure
- ...
- $ make
- ...
使用者通常不關心遠端建構功能，因為所有他們需要做的是配置，建構，和安裝你的代碼到他們的平台上。另一方面，維護者發現遠端建構功能非常有用，因為它允許他們為工程維護多個建構環境，每一個用複雜的配置選項。不用重新配置一個單一的建構環境，維護者可以簡單地切換到另一個用不同選項配置的建構目錄。
運作make
最後，運作普通的make。Autotools的設計者去了很多麻煩來確定你不必使用任何特定的make版本或分支。圖1-5揭示了在建構過程中生成的make檔案同make之間的内部關系。
如你所見，make運作了幾個生成的腳本，但是這些所有都是對make過程輔助的。生成的make檔案包含在合适條件下執行這些腳本的指令。這些腳本是Autotools的一部分，它們要麼是在你的軟體包裡附帶，要麼是由你的配置腳本生成。
安裝最新的Autotools
如果你正運作一個Linux的變種，并且你已選擇安裝編譯器和工具用于開發C語言軟體，你很可能已經有Autotools的一些版本安裝在你的系統上了。為确定你正使用的autoconf，automake和libtool的版本，僅僅打開一個終端視窗，鍵入下列指令：
[cpp] view plain copy print ?
- $ which autoconf
- /usr/local/bin/autoconf
- $ autoconf --version
- autoconf (GNU Autoconf) 2.65
- Copyright (C) 2009 Free Software Foundation, Inc.
- License GPLv3+/Autoconf: GNU GPL version 3 or later
- <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law.
- Written by David J. MacKenzie and Akim Demaille.
- $
- $ which automake
- /usr/local/bin/automake
- $ automake --version
- automake (GNU automake) 1.11
- Copyright (C) 2009 Free Software Foundation, Inc.
- License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-
- 2.0.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law.
- Written by Tom Tromey <[email protected]>
- and Alexandre Duret-Lutz <[email protected]>.
- $
- $ which libtool
- /usr/local/bin/libtool
- $ libtool --version
- ltmain.sh (GNU libtool) 2.2.6b
- Written by Gordon Matzigkeit <[email protected]>, 1996
- Copyright (C) 2008 Free Software Foundation, Inc.
- This is free software; see the source for copying conditions. There is NO
- warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- $
注意：如果你已在系統上安裝了Autotools軟體包的Linux釋出版本，可執行檔案可能會在/usr/bin中發現，而不是/usr/local/bin。
如果你選擇下載下傳，建構和安裝來自GNU網站的這些軟體包的最新版本，你必須為它們做相同的事，因為automake和libtool軟體包安裝宏到Autoconf的宏目錄中。如果你還沒有安裝Autotools，你可以使用下列指令安裝來自GNU釋出版軟體源檔案的它們。(如有必要，確定修改版本号)
[cpp] view plain copy print ?
- $ mkdir autotools && cd autotools
- $ wget -q ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz
- $ gzip -cd autoconf* | tar xf -
- $ cd autoconf*
- $ ./configure && make all check
- ...
- $ su
- Password: ******
- # make install
- ...
- # exit
- $ cd ..
- $
- $ wget -q ftp://ftp.gnu.org/gnu/automake/automake-1.11.tar.gz
- $ gzip -cd automake* | tar xf -
- $ cd automake*
- $ ./configure && make all check
- ...
- $ su
- Password: ******
- # make install
- # exit
- $ cd ..
- $
- $ wget -q ftp://ftp.gnu.org/gnu/libtool/libtool-2.2.6b.tar.gz
- $ gzip -cd libtool* | tar xf -
- $ cd libtool*
- $ ./configure && make all check
- ...
- $ su
- Password: ******
- # make install
- ...
- # exit
- $ cd ..
- $
現在你可以成功地執行來自前一樣例的版本檢查指令。
總結
在這章中，我們已闡述了Autotools的高層概要，來給你一個每個事物是如何聯系在一起的感覺。我也已給你展示了當你建構由Autotools編譯系統建立的釋出版本的軟體時，可遵循的方法。最後，我已講明如何安裝Autotools，如何知道你已安裝的版本。
在第二章中，我們會短暫地遠離Autotools，開始為一個稱為Jupiter的玩具工程建立一個手工編碼的編譯系統。你會學習一個合理的編譯系統的需求，并且你會熟悉Autotools原始設計之後的解釋。有了這個背景知識，你會開始明白Autotools所做事情的緣由。我真的無法足夠去強調：第2章是本書最重要的章節之一。