autoconf手冊（八）
2024-07-21 02:35:58
供稿：網(wǎng)友
我如何解開死結(jié)?
假如Autoconf需要GNU m4并且GNU m4還有一個(gè)Autoconf configure腳本，
我如何解開這個(gè)死結(jié)？它似乎是一個(gè)類似于雞和蛋的問題！
這實(shí)際上是一種誤解。雖然GNU m4帶有一個(gè)由Autoconf生成的configure腳本，但在運(yùn)行腳本及安裝GNU m4的時(shí)候并不需要安裝Autoconf。只有在你需要修改m4的configure 腳本的時(shí)候，這只是少數(shù)幾個(gè)人（主要是它的維護(hù)者）必須去作的事，才需要Autoconf。
為什么不使用Imake?
為什么不用Imake來代替configure腳本？
有些人已經(jīng)提出了這個(gè)問題，所以在改編之后，我把給他們的解釋寫在這里。
下面是對Richard Pixley的問題的回答：
由Autoconf生成的腳本經(jīng)常地在它以前從未設(shè)置過的機(jī)器上工作。這就是說，它善于推斷新系統(tǒng)的配置。而Imake不能做到。
Imake使用含有主機(jī)特定數(shù)據(jù)的通用數(shù)據(jù)庫。對X11來說，這種方法具有意義是因?yàn)榘l(fā)布版本是由一個(gè)控制整個(gè)數(shù)據(jù)庫的總管機(jī)關(guān)治理的一組工具組成的。
GNU工具并不按這種方式發(fā)行。每個(gè)GNU工具都有一個(gè)維護(hù)者；這些維護(hù)者散布在世界各地。使用統(tǒng)一的數(shù)據(jù)庫將使維護(hù)變成噩夢。 Autoconf可能成為這類數(shù)據(jù)庫，但實(shí)際上它沒有。不是列舉主機(jī)的依靠性，它列舉的是程序的需求。
假如你把GNU套件看作一組本地工具，那么問題就很相似了。但GNU開發(fā)工具可以作為交叉工具（cross tools）而在幾乎所有主機(jī)+目標(biāo)機(jī)的組合中進(jìn)行配置。所有的這些配置都可以同時(shí)（concurrency）安裝。它們甚至可以被配置成可以在不同主機(jī)上共享與主機(jī)獨(dú)立的信息的形式。Imake不能處理這些問題。
Imake模板是標(biāo)準(zhǔn)的一種形式。GNU編碼標(biāo)準(zhǔn)在沒有強(qiáng)加相同的限制的情況下，解決了相同的問題。
下面是一些由Per Bothner撰寫的進(jìn)一步的解釋：
Imake的一個(gè)優(yōu)點(diǎn)是它易于通過使用cpp的`#include'和宏機(jī)制生成大的Makefile。然而，cpp是不可編程的：它含有有限的條件工具，而不含有循環(huán)。而且cpp不能檢查它的環(huán)境。
所有這些問題可以通過使用sh而不是cpp來解決。shell是完全可編程的、含有宏替換、可以執(zhí)行（或者編制）其它的shell腳本，并且可以檢查它的環(huán)境。
Paul Eggert更具體地闡述：
使用Autoconf，安裝者不必假定Imake自身已經(jīng)被安裝并且正常地工作了。這對于習(xí)慣使用Imake的人們來說，看起來不是突出的優(yōu)點(diǎn)。但在許多主機(jī)上，并沒有安裝Imake或者缺省的安裝不能很好地工作，為此，要求安裝Imake就阻礙了在這些主機(jī)上使用由Imake配置的軟件包。例如，Imake模板和配置文件可能不能適當(dāng)?shù)匕惭b在一個(gè)主機(jī)上，或者Imake創(chuàng)建過程可能會錯(cuò)誤地假定所有的源代碼文件都在一個(gè)大目錄樹中，或者Imake配置可能使用某個(gè)編譯器而包或者安裝器需要使用另一個(gè)編譯器，或者包需要的Imake的版本號與系統(tǒng)支持的版本號不匹配。這些問題在Autoconf中很少出現(xiàn)，這是因?yàn)榘綆儆谒约旱莫?dú)立配置處理器。
還有，Imake通常會在make和安裝者的C預(yù)處理器之間碰到難以預(yù)期的影響。這里的基本問題是，C預(yù)處理器是為處理C程序而不是`Makefile'而設(shè)計(jì)的。這對Autoconf來說問題小得多，它使用通用目的預(yù)處理器m4，并且包的作者（而不是安裝者）以標(biāo)準(zhǔn)的方式進(jìn)行預(yù)處理。
最后，Mark Eichin解釋道：
Imake還不是完全可擴(kuò)展的。為了把新特征添加到Imake中，你需要提供你自己的項(xiàng)目模板，并且復(fù)制已經(jīng)存在的特征的主要部分。這意味著對于復(fù)雜的項(xiàng)目來說，使用由買主提供的（vendor-PRovided）Imake模板不能提供任何平衡作用--這是因?yàn)樗鼈儾话阕约旱捻?xiàng)目的任何東西（除非它是一個(gè)X11程序）。
但是，另一方面：
一個(gè)Imake勝過configure的優(yōu)點(diǎn)是： `Imakefile'總是趨向于比`Makefile.in'簡短（同樣地，冗余較少）。但是，這兒有一個(gè)修正的方法--至少對于Kerberos V5樹來說，我們已經(jīng)在整個(gè)樹中進(jìn)行了修改以調(diào)用通用的 `post.in'和`pre.in' `Makefile'片斷。這意味著大部分通用的東西，即使它們通常是在configure中設(shè)置的，也不必復(fù)制。
從版本1中升級
Autoconf第2版基本上與第1版是向后兼容的。但是，它給出了作某些事的更好方法，并且不再支持版本1中一些丑陋的東西。因此，根據(jù)你的`configure.in'文件的復(fù)雜性，你可能必須作一些手工的工作以升級到版本2。本章指出了一些在升級的時(shí)候需要注重的問題。還有，可能你的configure腳本可以從版本2中的新特征中獲得一些好處；在Autoconf發(fā)布包中的`NEWS'文件概括了改變的部分。
首先，確認(rèn)你安裝了1.1版或者更高版本的GNU m4，最好是1.3版或者更高版本。在1.1版之前的版本含有bug 以至于它不能與Autoconf版本2一同工作。版本1.3及其后的版本比早期的版本更快一些，這是因?yàn)?.3版的GNU m4 對轉(zhuǎn)換（diversions）進(jìn)行了更有效的實(shí)現(xiàn)并且能夠在可以快速讀回的文件中凍結(jié)（freeze）它的內(nèi)部狀態(tài)。
改變了的文件名
假如你隨Autoconf一起安裝了`aclocal.m4'（相對于特定軟件包的源代碼目錄中的`aclocal.m4'），你必須把它重命名為`acsite.m4'。參見用autoconf創(chuàng)建configure。
假如你與你的軟件包一同發(fā)布`install.sh'，就把它重命名為`install-sh'以便make的內(nèi)置規(guī)則不會無意地從該文件創(chuàng)建一個(gè)稱為`install'的文件。
AC_PROG_INSTALL將尋找這兩個(gè)名字的腳本，但最好使用新名字。
假如你使用`config.h.top'或者`config.h.bot'，你仍然可以使用它們，但假如你把它們混合到 `acconfig.h'之中，將減少你的麻煩。參見用autoheader創(chuàng)建`config.h.in'。
改變了的Makefile
在你的`Makefile.in'文件中添加`@CFLAGS@'、`@CPPFLAGS@'和`@LDFLAGS@'，以便它們可以在configure運(yùn)行的時(shí)候利用環(huán)境中的這些變量的值。這樣做不是必須的，但對用戶來說比較方便。
對于AC_OUTPUT的每個(gè)非`Makefile'的輸入文件，你還應(yīng)該添加一條含有 `@configure_input@'的注釋，以便輸出文件將會包含一條注釋以說明它們是由configure生成的。自動(dòng)地為每種人們在AC_OUTPUT中輸出的文件選擇正確的注釋語法需要做太多的工作。
把`config.log'和`config.cache'添加到你要在distclean目標(biāo)中刪除的文件的列表中。
假如你的`Makefile.in'如下：
prefix = /usr/local
exec_prefix = ${prefix}
你必須把它修改成：
prefix = @prefix@
exec_prefix = @exec_prefix@
不使用`@'字符的老式的對這些變量的替換行為已經(jīng)被刪除了。
改變了的宏
在Autoconf第2版中，重新命名了許多宏。你仍然可以使用舊名字，但新名字更清楚，并且易于找到相關(guān)文檔。關(guān)于為舊宏名提供新宏名的列表，參見陳舊的宏名。用autoupdate程序轉(zhuǎn)換你的`configure.in'以使用新的宏名。參見用autoupdate更新configure。
有些宏已經(jīng)被能夠更好地完成工作的類似宏所代替，但在調(diào)用上并不兼容。假如你在運(yùn)行autoconf時(shí)受到了關(guān)于調(diào)用過時(shí)宏的警告，你可以安全地忽略它們，但假如你按照打印的建議替換過時(shí)的宏，你的configure腳本通常可以工作的更好。非凡地，報(bào)告測試結(jié)果的機(jī)制已經(jīng)改變了。假如你使用了echo或者AC_VERBOSE（可能是通過AC_COMPILE_CHECK），假如你改用AC_MSG_CHECKING和AC_MSG_RESULT，你的configure腳本的輸出將更加美觀。參見打印消息。這些宏能夠更好地與緩存變量協(xié)同工作。參見緩存結(jié)果。
用autoupdate更新configure
程序autoupdate把使用Autoconf舊宏名的`configure.in'文件更新為使用當(dāng)前宏名的文件。在Autoconf第2版中，大部分宏被重命名以使用一個(gè)更統(tǒng)一、更具有描述性的命名機(jī)制。關(guān)于對新的命名機(jī)制的描述，參見宏名。雖然舊宏名仍然可以工作（關(guān)于舊宏名和對應(yīng)的新宏名的列表，參見陳舊的宏名），假如你更新它們以使用新的宏名，你可以使你的 `configure.in'文件更加可讀并且易于使用當(dāng)前的Autoconf文檔。
假如沒有給出參數(shù)，autoupdate就更新`configure.in'，并且通過添加后綴`~' （或者在設(shè)置了環(huán)境變量SIMPLE_BACKUP_SUFFIX的時(shí)候，使用該環(huán)境變量的值）以備份原始版本。假如你帶參數(shù)調(diào)用autoupdate，它就讀入那個(gè)文件而不是讀入`configure.in'，并且把更新的文件輸出到標(biāo)準(zhǔn)輸出。
autoupdate接受下列選項(xiàng)：
--help
-h
打印命令行選項(xiàng)的概述并且退出。
--macrodir=dir
-m dir
在目錄dir中，而不是在缺省安裝目錄中尋找Autoconf宏文件。你還可以把環(huán)境變量AC_MACRODIR設(shè)置成一個(gè)目錄；本選項(xiàng)覆蓋該環(huán)境變量。
--version
打印autoupdate的版本號并且退出。
改變了的結(jié)果
假如你通過檢驗(yàn)shell變量DEFS來檢驗(yàn)以前測試的結(jié)果，你需要把這些檢驗(yàn)替換為對那些測試的緩存變量的檢查。在configure運(yùn)行的時(shí)候，DEFS不再存在；它僅僅在生成輸出文件的時(shí)候才被創(chuàng)建。這種與第1版的不同是因?yàn)檎_地對變量實(shí)行引用（quoting）實(shí)在太麻煩而且在每次調(diào)用AC_DEFINE都要實(shí)行引用是低效的。參見緩存變量名。
例如，下面是為Autoconf第1版編寫的`configure.in'的片斷：
AC_HAVE_FUNCS(syslog)
case "$DEFS" in
*-DHAVE_SYSLOG*) ;;
*) # syslog is not in the default libraries.See if it's in some other.
saved_LIBS="$LIBS"
for lib in bsd socket inet; do
AC_CHECKING(for syslog in -l$lib)
LIBS="$saved_LIBS -l$lib"
AC_HAVE_FUNCS(syslog)
case "$DEFS" in
*-DHAVE_SYSLOG*) brea
