原文:http://os.51cto.com/art/201609/518191.htm 經常使用Linux的開發人員或者運維人員,可能對configure->make->make install相當熟悉。事實上,這叫GNU構建系統,利用腳本和make程式在特定平臺上構建軟體。這種方式成為一種習慣, ...
原文:http://os.51cto.com/art/201609/518191.htm
經常使用Linux的開發人員或者運維人員,可能對configure->make->make install相當熟悉。事實上,這叫GNU構建系統,利用腳本和make程式在特定平臺上構建軟體。這種方式成為一種習慣,被廣泛使用。本文從用戶視角和開發者視角詳細說明,這種構建方式的細節,以及開發者如何利用autoconf和automake等工具(autotools)創建相容GNU構建系統的項目。
為了簡化可移植構建的難度,在早期有一套autotools工具幫助程式員構建軟體。我們熟知的configure->make->make install三部曲,大多都是基於autotools來構建的。autotools是GNU程式的標準構建系統,所以其實我們經常在使用三部曲。有些程式雖然也是這三部曲,但卻不是用autotools實現的,比如nginx的源碼就是作者自己編寫的構建程式。
用戶視角
用戶通過configure->make->make install基於源碼安裝軟體。然而大部分用戶可能並不知道這個過程究竟做了些什麼。
configure腳本是由軟體開發者維護併發布給用戶使用的shell腳本。這個腳本的作用是檢測系統環境,最終目的是生成Makefile和config.h。
make通過讀取Makefile文件,開始構建軟體。而make install可以將軟體安裝到需要安裝的位置。
如上圖,開發者在分發源碼包時,除了源代碼(.c .h…),還有許多用以支撐軟體構建的文件和工具,其中最重要的文件就是Makefile.in和config.h.in。configure腳本執行成功後,將為每一個*.in文件處理成對應的非*.in文件。
大部分情況只生成Makefile和config.h,因為Makefile用於make程式識別並構建軟體,而config.h中定義的巨集,有助於軟體通過預編譯來改變自身的代碼,以適應目標平臺某些特殊性。有些軟體在configure階段,還可以生成其他文件,這完全取決於如軟體本身。
configure
當運行configure時,將看到類似如下的系統檢查,這些檢查的多少取決於軟體本身的需要,也就是由軟體開發者來定義和編寫的。
- checking for a BSD-compatible install... /usr/bin/install -c
- checking whether build environment is sane... yes
- checking for a thread-safe mkdir -p... /bin/mkdir -p
- checking for gawk... gawk
- checking whether make sets $(MAKE)... yes
- checking for gcc... gcc
- checking for C compiler default output file name... a.out
- ...
一般來說,configure主要檢查當前目標平臺的程式、庫、頭文件、函數等的相容性。這些檢查結果將作用於config.h和Makefile文件的生成。從而影響最終的編譯。
用戶也可以通過給configure配置參數來定製軟體需要包含或不需要包含的組件、安裝路徑等行為。這些參數分為5組,可以通過執行./configure --help來查看,軟體提供哪些配置參數:
- *安裝路徑相關配置。最常見的是--prefix。
- *程式名配置。例如--program-suffix可用於為生成的程式添加尾碼。
- *跨平臺編譯。不太常用。
- *動態庫靜態庫選項。用於控制是否生成某種類型的庫文件。
- 程式組件選項。用於配置程式是否將某種功能編譯到程式中,一般形如--with-xxx。這可能是最常用的配置,而且由軟體開發者來定義。
(*表示這是幾乎所有軟體都支持的配置,因為這些配置是autotool生成的configure腳本預設支持的。)
configure在執行過程中,除了生成Makefile外,還會生成的文件包括但不限於:
- config.log 日誌文件
- config.cache 緩存,以提高下一次configure的速度,需通過-C來指定才會生成
- config.status 實際調用編譯工具構建軟體的shell腳本
如果軟體通過libtool構建,還會生成libtool腳本。關於libtool腳本如何生成,請看開發者視角。
configure經常會中途出錯,這一般是由於當前平臺不具有構建該軟體所必需的依賴(庫、函數、頭文件、程式…)。此時,不要慌張,仔細查看輸出,解決這些依賴。
開發者視角
開發者除了編寫軟體本身的代碼外,還需要負責生成構建軟體所需要文件和工具。當我接觸到autotools後,我發現,雖然有工具的幫助,但這件事情依舊十分複雜。
對於C或C++程式員,在早期,構建跨平臺的應用程式是相當繁瑣的一件事情,而且對於經驗不足的程式員而言,甚至難度巨大。因為構建可移植的程式的必要前提是對各個平臺足夠瞭解,這往往要花上相當長的時間去積累。
Unix系統的分支複雜度很高,不同的商用版或開源版或多或少都有差異。這些差異主要體現在:系統組件、系統調用。我們主要將Unix分為如下幾個大類:IBM-AIX HP-UX Apple-DARWIN Solaris Linux FreeBSD。Unix分支大全
因此,對於開發者而言,要麼自己編寫構建用的腳本,這往往需要極其扎實的shell能力和平臺熟悉度。另一個選擇就是部分依賴工具。autoconf和automake就是這樣的工具。
autoreconf
為了生成configure腳本和Makefile.in等文件,開發者需要創建並維護一個configure.ac文件(在早期,通常叫configure.in文件,雖然沒有區別,但強烈建議使用.ac,因為.in文件往往意味著被configure腳本識別為模板文件並生成直接參与最終構建的文件,configure.in在命名上有歧義),以及一系列的Makefile.am。autoreconf程式能夠自動按照合理的順序調用autoconf automake aclocal等程式。
configure.ac
configure.ac用於生成configure腳本。autoconf工具用來完成這一步。下麵是一個configure.ac的例子:
- AC_PREREQ([2.63])
- AC_INIT([st], [1.0], [[email protected]])
- AC_CONFIG_SRCDIR([src/main.c])
- AC_CONFIG_HEADERS([src/config.h])
- AM_INIT_AUTOMAKE([foreign])
- # Checks for programs.
- AC_PROG_CC
- AC_PROG_LIBTOOL
- # Checks for libraries.
- # Checks for header files.
- # Checks for typedefs, structures, and compiler characteristics.
- # Checks for library functions.
- AC_CONFIG_FILES([Makefile
- src/Makefile
- src/a/Makefile
- src/b/Makefile])
- AC_OUTPUT
其中以AC_開頭的類似函數調用一樣的代碼,實際是一些被稱為“巨集”的調用。這裡的巨集與C中的巨集概念類似,會被替換展開。m4是一個經典的巨集工具,autoconf正是構建在m4之上,可以理解為autoconf預先實現了大量的,用於檢測系統可移植性的巨集,這些巨集在展開後就是大量的shell腳本。所以編寫configure.ac需要對這些巨集熟練掌握,並且合理調用。有時,甚至可以自己實現自己的巨集。
autoscan和configure.scan
可以通過調用autoscan命令得到一個初始化的configure.scan文件,然後重命名為configure.ac後,在此基礎上編輯configure.ac。autoscan會掃描源碼,並生成一些通用的巨集調用、輸入的聲明以及輸出的聲明。儘管autoscan十分方便,但是沒人能夠在構建之前,就把代碼完全寫好,因此autoscan通常用於初始化configure.ac。
autoheader和config.h
autoheader命令掃描configure.ac中的內容,並確定需要如何生成config.h.in。每當configure.ac有所變化,都可以通過再次執行autoheader更新config.h.in。在configure.ac通過AC_CONFIG_HEADERS([config.h])告訴autoheader應當生成config.h.in的路徑。在實際的編譯階段,生成的編譯命令會加上-DHAVE_CONFIG_H定義巨集,於是在代碼中,我們可以通過下麵代碼安全的引用config.h。
- /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H ...
- #ifdef HAVE_CONFIG_H
- #include <config.h>
- #endif
config.h包含了大量的巨集定義,其中包括軟體包的名字等信息,程式可以直接使用這些巨集;更重要的是,程式可以根據其中的對目標平臺的可移植性相關的巨集,通過條件編譯,動態的調整編譯行為。
automake和Makfile.am
手工編寫Makefile是一件相當煩瑣的事情,而且,如果項目複雜的話,編寫難度將越來越大。因而,automake工具應運而生。我們可以編寫像下麵這樣的Makefile.am文件,並依靠automake來生成Makefile.in:
- SUBDIRS = a b
- bin_PROGRAMS = st
- st_SOURCES = main.c
- st_LDADD = $(top_builddir)/src/a/liba.la $(top_builddir)/src/b/libb.la
這裡通過SUBDIRS聲明瞭兩個子目錄,子目錄的中的構建需要靠a/Makefile.am和b/Makefile.am來進行,這樣多目錄組織起來就方便多了。
bin_PROGRAMS聲明一個可執行文件目標,st_SOURCES指定這個目標所依賴的源代碼文件。另外,st_LDADD聲明瞭可執行文件在連接時,需要依賴的Libtool庫文件。
通過這個Makefile.am文件生成的Makefile.in文件相當大,不便貼出,但是可以想象,Makefile.in要比我們手工編寫的Makefile文件複雜的多。
automake的出現晚於autoconf,所以automake是作為autoconf的擴展來實現的。通過在configure.ac中聲明AM_INIT_AUTOMAKE告訴autoconf需要配置和調用automake。
aclocal
上面提到,configure.ac實際是依靠巨集展開來得到configure的。因此,能否成功生成取決於,巨集定義能否找到。autoconf會從自身安裝路徑下來尋找事先定義好了巨集。然而對於像automake、libtool和gettext等第三方擴展巨集,甚至是開發者自行編寫的巨集就一無所知了。於是,存在這個工具aclocal,將在configure.ac同一目錄下生成aclocal.m4,在掃描configure.ac的過程中,將第三方擴展和開發者自己編寫的巨集定義複製進去。這樣,autoconf在遇到不認識的巨集時,就會從aclocal.m4中查找。
下麵這張圖更為詳細的展現了整個工具鏈是如何互相配合的。
libtool
libtool試圖解決不同平臺下,庫文件的差異。libtool實際是一個shell腳本,實際工作過程中,調用了目標平臺的cc編譯器和鏈接器,以及給予合適的命令行參數。libtool可以單獨使用,這裡只介紹與autotools集成使用相關的內容。
automake支持libtool構建聲明。在Makefile.am中,普通的庫文件目標寫作xxx_LIBRARIES:
- noinst_LIBRARIES = liba.a
- liba_SOURCES = ao1.c ao2.c ao3.c
而對於一個libtool目標,寫作xxx_LTLIBRARIES,並以.la作為尾碼聲明庫文件。
- noinst_LTLIBRARIES = liba.la
- liba_la_SOURCES = ao1.c ao2.c ao3.c
在configure.ac中需要聲明LT_INIT:
- ...
- AM_INIT_AUTOMAKE([foreign])
- LT_INIT
- ...
有時,如果需要用到libtool中的某些巨集,則推薦將這些巨集copy到項目中。首先,通過AC_CONFIG_MACRO_DIR([m4])指定使用m4目錄存放第三方巨集;然後在最外層的Makefile.am中加入ACLOCAL_AMFLAGS = -I m4。
all-in-one
上面討論了很多關於autoreconf的細節。實際上,如今我們可以直接調用autoreconf --install來自動調用上面提到的所有子命令。這裡--install參數試圖將輔助的腳本和巨集copy到當前項目目錄中,下麵是執行時的輸出:
- autoreconf: Entering directory `.'
- autoreconf: configure.ac: not using Gettext
- autoreconf: running: aclocal
- autoreconf: configure.ac: tracing
- autoreconf: running: libtoolize --copy
- libtoolize: putting auxiliary files in `.'.
- libtoolize: copying file `./ltmain.sh'
- libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
- libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
- libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
- autoreconf: running: /usr/bin/autoconf
- autoreconf: running: /usr/bin/autoheader
- autoreconf: running: automake --add-missing --copy --no-force
- configure.ac:10: installing `./config.guess'
- configure.ac:10: installing `./config.sub'
- configure.ac:9: installing `./install-sh'
- configure.ac:9: installing `./missing'
- src/Makefile.am: installing `./depcomp'
- autoreconf: Leaving directory `.'
當我們以--install參數運行時,libtoolize --copy被調用,這將使得ltmain.sh被copy進來;接下來分別執行autoconf和autoheader;automake的參數為--add-missing --copy --no-force,這將使得幾個輔助腳本和文件被安裝到目錄下。
這些輔助文件預設安裝在configure.ac同一個目錄下,如果你希望用另一個目錄來存放他們,可以配置AC_CONFIG_AUX_DIR,例如AC_CONFIG_AUX_DIR([build-aux])將使用build-aux目錄來存放輔助文件。
如果不使用--install參數,輔助文件要麼不copy,要麼以軟鏈的形式創建。推薦使用--install,因為這樣,其他軟體維護可以避免由於構建工具版本不一致造成問題。
輔助文件
一個依靠GNU構建系統開發的軟體除了源碼之外,還有很多輔助的文件,有些是腳本,有些是文本文件。下麵將逐一解釋這些文件:
- aclocal.m4:上面提到了,這個巨集定義文件裡面包含了第三方的巨集定義,用於autoconf展開configure.ac
- NEWS README AUTHORS ChangeLog:這些文件是GNU軟體的標配,不過在項目中不一定需要加入。如果項目中沒有這些文件,每次autoreconf會提示缺少文件,不過這並不影響。如果不想看到這些錯誤提示,可以用AM_INIT_AUTOMAKE([foreign])來配置automake。foreign參數就是告訴automake不要這麼較真:)
- config.guess config.sub:由automake產生,兩個用於目標平臺檢測的腳本
- depcomp install-sh:由automake產生,用於完成編譯和安裝的腳本
- missing:由automake產生
- ltmain.sh:有libtoolize產生,該腳本用於在configure階段配置生成可運行於目標平臺的libtool腳本
- ylwrap:由automake產生,如果檢測構建需要使用lex和yacc,那麼會產生這個包裝腳本
- autogen.sh:在早期,autoreconf並不存在,軟體開發者往往需要自己編寫腳本,按照順序調用autoconf autoheader automake等工具程式。這個文件就是這樣的腳本。起這麼個名字可能是習慣性的
總結
本文總概念上闡述了autotool系列工具是如何工作的。相比如今現成的IDE,GNU構建系統其實是非常難用的,學習成本比較高。筆者認為最為效率的途徑是學習開源的程式,從中慢慢體會,慢慢吸收。另外,推薦幾個資料:
- 《GNU Autoconf Automake and Libtool》
- Autotools Tutorial
- GNU網站上關於autoconf automake 和 libtool的手冊