Autotools發展史

在linux下面擼過代碼、做過開發的，想必都聽說過Makefile。

對，是Makefile，不是make love。如果你看成了后者，只能說：同志，你的三觀有問題，需要格式化你的硬盤~

在linux開發程序，沒有集成開發環境IDE(integrated development environment),沒有VC++6.0，

只有Makefile和冰冷黑漆漆的shell窗口，寒冷的夜，考驗著每一個工程師疲憊的心

Makefile語法復雜、難以維護。對于一個小項目還好，對于大型的項目和開源項目，現在流行使用一些工具自動生成Makefile，可以大大減輕軟件開發人員的負擔。

比較常見的工具有GNU Autotools、CMake、QMake、SCons、Ant等。今天講講GNU Autotools，這個工具在開源軟件和大型項目中被廣泛地使用。

Autotools主要有Autoconf、automake、libtool等軟件包工具組成，我們可以稱為Autotools三劍客。

使用這幾個工具，雖然能幫助我們自動生成Makefile，但是命令過程復雜，中間會生成大量的各種配置文件和腳本。很多人往往會覺得很麻煩、搞不懂里面錯綜復雜的關系，今天以這些工具的發展過程，給大家理理里面的關系。

一、手工makefile時代

早期我們在Unix、linux環境下開發軟件，makefile都是手寫的。通過makefile，我們就可以使用make命令直接去編譯我們的源代碼。

后來，隨著Unix版本越來越多，各分支差異越來越大，我們寫的makefile，有時候在其它Unix平臺上可能就編譯失敗，比如庫的問題等。不同的操作系統版本，庫和頭文件的路徑可能不一樣。怎么辦？

后來我們通過手寫一個配置腳本configure來解決這個問題：針對你當前的Unix平臺，通過腳本對makefile進行配置，就可以在當前平臺上愉快地編譯了。

二、Autoconf時代

后來linux操作系統問世，后續的版本也越來越多，各種發布版本錯綜復雜，比如Redhat系列、debian系列等。差異越來越大，甚至包括操作系統的接口都出現差異。這時候別說makefile能不能正確編譯的問題了，就連我們編寫的應用程序，即使編譯正確，也有可能在其它的平臺上運行不起來。這個問題，大家都知道，后來出現了POSIX API標準，就是可移植的操作系統接口。就是無論你是發布什么版本的Unix、Linux，OS的接口要遵循這個標準，這樣我們編寫的應用程序才能在linux、Unix等系列版本的操作系統上暢通無阻地運行。

而對于makefile來說，為了適配操作系統的更多版本，只能不斷地添加代碼，這就導致configure腳本越來遠大，導致后來開發人員再也受不了了，維護成本越來越高。

1991年，David Mackenzie開發了Autoconf工具，用來自動生成configure腳本。因為對于大多數用戶來說，對于不同版本的差異、庫的版本、底層的細節，鬼才懶得管。他們關心的就是庫文件、頭文件的位置、軟件最終的安裝路徑是在哪里。所以這個工具的出現，大大解放了開發人員的時間，給廣大程序員帶來了福音。

用戶只需要定義幾個宏，表示我們關心的配置選項，保存在configure.ac文件里，然后使用Autoconf工具就可以幫我們自動生成configure腳本了！

Autoconf工具真是比大姨媽還貼心，為了減輕程序員的負擔，configure.ac文件也不用我們手寫了。Autoconf工具包里有個autoscan工具，可以自動掃描我們的項目，生成一個configure.scan文件，里面自動添加了很多宏，省得我們再手工添加。

我們只需要將這個configure.scan文件重命名為configure.ac文件，再修修補補，就可以了。

Autoconf工具大大減輕了程序員的負擔，媽媽，再也不用擔心晚回家吃飯了

三、automake時代

然而，隨著項目越來越大，makefile也越來越復雜，尤其是大型項目，手寫越來越困難，怎么辦？

automake工具這個時候閃亮登場了！

對于開發人員來說，我們關心的就是這個項目要生成什么可執行文件，需要編譯哪些源文件，至于怎么編譯的？底層的鏈接細節，鬼才懶得管。程序員的加班已經夠多，內心已經夠疲憊，我們拒絕makefile的肆虐和壓迫！

使用automake工具，我們只需要手工編寫一個makefile.am文件，在里面定義我們想要生成的目標、需要編譯的源文件，然后使用automake工具就可以幫我們自動生成makefile！

但是此時的makefile，是通用的makefile，定義了程序編譯、鏈接的通用規則，保存在makefile.in里面。

如果想在特定平臺上成功編譯，還需要我們前面的腳本configure配置一下，最終才生成我們項目的Makefile。

Autoconf工具通過定義一系列的宏，提供給我們使用，讓我們去設置一些需要的配置選項、去配置我們的makefile。

后來Automake工具出現后，自定義了一些宏，對這些宏進行了擴展。比如，Autoconf以前都是單獨使用的，現在要跟automake配合使用，要在configure.ac文件里添加一個AM_INIT_AUTOMAKE這個宏。

這個宏是在automake工具包里定義的，當我們運行autoconf命令的時候，就是出錯，因為找不到這個宏的定義。怎么辦，咋辦？

后來在configure.ac同目錄下，定義一個aclocal.m4格式的文件，里面存放用戶定義的一些宏、或者automake的一些宏，這樣，autoconf運行的時候，就可以在這個文件里找到宏定義了。

偷懶，是人類社會進步的最大動力。后來，為了進一步減少工作量，又出現一個aclocal工具，會自動將automake、autoconf以及用戶定義的所有宏統統放在aclocal.m4文件里。

為什么要保存在aclocal.m4這種格式的文件里？我也不知道....，m4，macro宏后面4個字母，縮寫就是m4.

文本文件嘛，后綴名可以隨便定義，比如我姓王，后綴名定義為.wang也是可以的。不要糾結于這些細節，我們的征途是構建makefile。

autoconf工具包里還有一個autoheader工具，用來將configure.ac里面的宏配置轉換為我們C語言格式的#define形式，并保存在config.h.in文件里，當我們運行./configure生成makefile的時候，順便也會將config.h.in轉換為config.h文件，這樣在我們的程序里，如果想使用這些宏，就可以直接#include “config.h”就可以了。

比如頭文件里面定義的軟件版本號VERSION宏，就可以在程序里直接使用，打印在程序里打印我們的軟件版本號。

四、libtool時代

隨著Unix、Linux之間的差異越來越大，對動態共享庫的管理差異也越來越大，比如有些共享庫，使用.so格式，有的是.a，有的是.o的形式。運行時對動態庫的管理方式也一樣，有的操作系統支持動態加載，有的就不支持。這就對我們Makefile帶來了挑戰。怎么辦？libtool的工具出現就是為了解決這個問題的，它通過對生成的動態庫進行抽象，統一生成.la的形式，可以支持十幾種各種不同的平臺。

具體的使用教程，可以參考我發布的視頻教程：《Makefile工程實踐》第二季--使用autotools自動構建項目的Makefile。