autoconf手冊（五）

[本文轉載來源為：http://doc.sheup.com/linux/linux403.htm]

獲取規範的系統類型

下列的宏使得configure腳本可以獲得系統類型。它們營運shell腳本config.guess以確定用戶在命令行中沒有給出的、它們需要的關於主機、目標和創建類型的所有值。它們營運config.sub對用戶給出的任何別名進行規範化。如果你使用這些宏,你必須把這兩個shell腳本與你的源代碼一同發布。關於 AC_CONFIG_AUX_DIR的訊息,你可以透過該宏設定configure查找這些腳本的目錄,請參見 創建輸出檔案。如果你沒有使用這些宏中的任意一個,configure 就忽略任何傳遞給它的``--host''、``--target''和``--build''選項。
宏︰ AC_CANONICAL_SYSTEM
檢測系統類型並把輸出變量設定成規範的系統類型。關於該宏設定變量的細節,參見系統類型變量。
宏︰ AC_CANONICAL_HOST
只執行AC_CANONICAL_SYSTEM中關於主機類型功能的子集。對於不是編譯工具鏈（compiler toolchain）一部分的程式,這就是所需要的全部功能。
宏︰ AC_VALIDATE_CACHED_SYSTEM_TUPLE (cmd)
如果緩存檔案與當前主機、目標和創建系統類型不一致,就執行cmd或者列印一個缺省的錯誤消息。

系統類型變量
在調用了AC_CANONICAL_SYSTEM之後,下列輸出變量包含了系統類型訊息。在調用了AC_CANONICAL_HOST 之後,只設定了下列host變量。
build,host,target

規範系統名稱；
build_alias,host_alias,target_alias
如果使用了config.guess,就是用戶指定的名稱或者規範名稱；
build_cpu,build_vendor,build_os
host_cpu,host_vendor,host_os
target_cpu,target_vendor,target_os
為方便而提供的規範名稱的獨立部分。
使用系統類型
你將如何使用規範的系統類型？通常,你在``configure.in''中的一個或多個case語句中使用它來選擇系統特定的C檔案。而後把那些使用基於系統名的檔案名的檔案連接到諸如``host.h''或``target.c''的普通的檔案上。case語句模型允許使用shell萬用字元對多種情況進行編組,就像下面的片斷︰

case ""$target"" in
i386-*-mach* i386-*-gnu*) obj_format=aout emulation=mach bfd_gas=yes ;;
i960-*-bout) obj_format=bout ;;
esac
宏︰ AC_LINK_FILES (source...,dest...)
使得AC_OUTPUT把每個存在檔案的source連接到對應連接名dest。如果可能,創建一個符號連接,否則就創建硬連接。dest和source應該是相對於頂層源代碼目錄或者創建目錄的相對路徑。可以多次調用本宏。

例如,下列調用︰
AC_LINK_FILES(config/${machine}.h config/${obj_format}.h,host.h object.h)

在當前目錄中創建``host.h'',它是一個到``srcdir/config/${machine}.h''的連接,並且創建``object.h'',它是一個到``srcdir/config/${obj_format}.h''的連接。
你還可以使用主機系統類型以尋找交叉編譯工具。關於完成該任務的宏AC_CHECK_TOOL的訊息,參見對普通程式和檔案的檢查。

站點配置
configure腳本支援幾種本地配置決策模式。它們是用戶指明外部軟體的位置,包括或除去可選的特徵,以修改過的名稱安裝的程式,以及為configure選項設定缺省值的手段。

與外部軟體一起工作
有些套裝軟件需要,或者可選地使用其它已經安裝的套裝軟件。用戶可以把命令行選項傳遞給configure 以指明使用那個外部軟體。選項採用下列形式之一︰
--with-package[=arg]
--without-package
例如,``--with-gnu-ld''的意思是使用GNU連接器而不是任何其它連接器。``--with-x''的意思是使用X Window系統。

用戶可以給出包名加``=''加參數的命令行參數。``no''是關於包的缺省參數；它表示不使用包。既不是``yes''又不是``no''的參數將包含其它包的名字或者版本號,以便更精確地指定本程式可以與之協同工作的包。如果沒有給出參數,``--without-package''的缺省參數為``yes''。 ``--without-package''等價於``--with-package=no''。

configure腳本並不對它們不支援的``--with-package''選項發出警告。本特徵允許頂層目錄中的configure腳本配置一個包含多個包的源代碼樹。在包支援不同的選項的時候,不會因為給出了只有一部分包支援的選項而導致不必要的錯誤消息。一個不幸的副作用是選項的拼寫錯誤就不能被檢查出來了。迄今為止還沒有處理該問題的更好辦法。

對於每個可能使用的外部套裝軟件,``configure.in''都應該調用AC_ARG_WITH以檢測 configure的用戶是否要求使用它。確定在缺省狀態下,是使用還是不使用每個包,以及那個參數是合法的,是你的任務。
宏︰ AC_ARG_WITH (package,help-string [,action-if-given [,action-if-not-given]])
如果用戶以選項``--with-package''或者``--without-package''調用 configure,就營運shell命令action-if-given。如果兩個選項都沒有給出,就營運shell命令 action-if-not-given。名字package給出了本程式應該與之協同工作的其它套裝軟件。它應該僅僅由字母、數字和破折號（dashes）組成。

shell命令action-if-given可以透過shell變量withval得到選項的參數,該變量的值實際上就是把 shell變量with_package的值中的所有``-''字符替換為``_''而得的。如果你願意,可以使用變量with_package。

參數help-string是對選項的描述,它看起來應該像︰

--with-readline support fancy command line editing

如果需要給出更多的細節,help-string可能多於一行。只要確保``configure --help''中的列的排列就可以了。不要在求助字元串中使用tab。你將需要用``[''和``]''包圍它以生成前導空格。

宏︰ AC_WITH (package,action-if-given [,action-if-not-given])
這是不支援求助字元串的AC_ARG_WITH的過時版本。

選擇包選項
如果套裝軟件含有可選的編譯時（compile-time）特徵,用戶就可以在調用configure時使用命令行選項來指明是否編譯它們。選項採用如下形式之一︰

--enable-feature[=arg]
--disable-feature

這些選項允許用戶選擇可選的選項進行創建和安裝。``--enable-feature''選項永遠不要使特徵的行為變得不同或者導致一個特徵代替另一個特徵。它們只應該導致程式的一部分被創建而另一部分不創建。

用戶可以透過在特徵名之後添加``=''和參數來給出參數。給出參數``no''表示 不能使用該特徵。一個帶有參數的特徵看起來就像``--enable-debug=stabs''。如果沒有給出參數,它的缺省值就是``yes''。``--disable-feature''等價於 ``--enable-feature=no''。

configure腳本並不對它們所不支援的``--enable-feature''選項發出警告。本特徵允許頂層目錄中的configure腳本配置一個包含多個包的源代碼樹。在包支援不同的選項的時候,不會因為給出了只有一部分包支援的選項而導致不必要的錯誤消息。一個不幸的副作用是選項的拼寫錯誤就不能被檢查出來了。迄今為止還沒有處理該問題的更好辦法。

對於每個可選的特徵,``configure.in''都應該調用AC_ARG_ENABLE以檢測configure 的用戶是否要求把該特徵包含進來。確定在缺省情況下,每個特徵是否被包含進來,以及那些選項是合法的,是你的任務。
宏︰ AC_ARG_ENABLE (feature,help-string [,action-if-given [,action-if-not-given]])
如果用戶以選項``--enable-feature''或者``--disable-feature''調用 configure,就營運shell命令action-if-given。如果兩個選項都沒有給出,就營運shell命令 action-if-not-given。名稱feature表示可選的用戶級功能。它應該僅僅由字母、數字和破折號（dashes）組成。

shell命令可以透過訪問shell變量enableval來得到選項的參數,該變量的值實際上就是把shell變量 enable_feature的值中所有的``-''字符替換成``_''而得到的。如果你願意,可以使用變量enable_feature。help-string參數類似於 AC_ARG_WITH中相應的參數（參見與外部軟體一起工作）。

宏︰ AC_ENABLE (feature,action-if-given [,action-if-not-given])
這是不支援求助字元串的AC_ARG_ENABLE的過時版本。

配置站點細節
有些套裝軟件需要複雜的與站點相關（site-specific）的訊息。例如用於某種服務、公司名稱和email聯繫位址的主名（host names）。因為有些配置腳本是透過Metaconfig模式交互地詢問這些訊息生成的,人們有時對於按非交互模式,由Autoconf生成配置腳本如何獲取這些訊息感到困惑。

這些站點配置訊息應該被儲存在一個僅僅由用戶,而不是程式,編輯的檔案中。檔案的位置既可以基於 prefix變量,也可以是一個標準的位置,比如說用戶的home目錄。它甚至可能透過一個環境變量給出。程式應該在營運時,而不是在編譯時,檢查那個檔案。營運時配置對於用戶來說更為方便,並且使得配置過程比在配置時獲取這些訊息要簡單。關於存放數據檔案的地點的詳細訊息,參見GNU編碼標準中的 ``為安裝目錄而提供的變量''。

在安裝的時候改變程式的名稱
Autoconf支援在安裝程式的時候修改程式的名稱。為了使用這些變換,``configure.in''必須調用宏 AC_ARG_PROGRAM。
宏︰ AC_ARG_PROGRAM
把對被安裝的程式的名稱進行替換的sed命令序列存入輸出變量program_transform_name中。

如果把下列任意選項傳遞給了configure,程式名就據此進行變換。否則,如果已經調用了AC_CANONICAL_SYSTEM並且``--target''的值給出了與主機類型（用``--host''給出的,或者是在config.sub中設定的缺省值）不同的類型,就把末尾附加了破折號的目標類型作為前綴。否則,就不進行程式名變換。
轉換選項
你可以把下列命令行選項傳遞給configure以指定名稱的轉換︰

--program-prefix=prefix
為名稱添加前綴prefix；
--program-suffix=suffix
為名稱添加後綴suffix；
--program-transform-name=expression
對名字作sed替換expression。
轉換的例子
這些變換對於作為交叉編譯開發環境的一部分的程式是有用的。例如,用``--target=i960-vxworks''選項配置的營運在Sun 4上的交叉彙編器通常以``i960-vxworks-as''為名稱進行安裝,而不是以``as''為名安裝,該名稱將於原來的Sun 4彙編器混淆。

如果你不希望安裝在你的系統上的GNU程式遮蔽具有相同名稱的其它程式,你可以強行要求程式名以``g''開頭。例如,如果你使用``--program-prefix=g''來配置GNU diff,那麼在你營運``make install'' 的時候,它就安裝到``/usr/local/bin/gdiff''。

作為更複雜的例子,你可以使用

--program-transform-name=''s/^/g/; s/^gg/g/; s/^gless/less/''

在源代碼樹中的大部分程式的名字之前附加``g'',已經含有一個``g''的程式,諸如gdb,和不是GNU程式的程式,比如說less和lesskey,除外。（它假定你有一個包含了設定成使用這些特徵的程式的源代碼樹。）

同時安裝某些程式的多個版本的一種方法是為其中一個程式的名稱或為所有程式的名稱附加版本號。例如,如果你還希望把 Autoconf版本1保留一段時間,你可以使用``--program-suffix=2''來配置Autoconf第2版,並且以名稱 ``/usr/local/bin/autoconf2''、``/usr/local/bin/autoheader2''等等來安裝程式。

轉換的規則
下面是如何在``Makefile.in''中使用變量program_transform_name︰

transform=@program_transform_name@
install: all
$(INSTALL_PROGRAM) myprog $(bindir)/``echo myprogsed ''$(transform)''``

uninstall:
rm -f $(bindir)/``echo myprogsed ''$(transform)''``

如果你要安裝多個程式,你可以透過一個循環來完成︰

PROGRAMS=cp ls rm
install:
for p in $(PROGRAMS); do
$(INSTALL_PROGRAM) $$p $(bindir)/``echo $$psed ''$(transform)''``;
done

uninstall:
for p in $(PROGRAMS); do
rm -f $(bindir)/``echo $$psed ''$(transform)''``;
done
是否在文檔檔案中進行變換（Texinfo或者man）是個麻煩的問題；由於名稱變換的幾個原因,好像不存在完美的答案。文檔對於特定的架構來說並不特殊,並且Texinfo檔案與系統文檔並不衝突。但它們可能與同一檔案的早期版本衝突,而且 man手冊有時與系統文檔衝突。作為一個折衷,可能最好是對man手冊進行名稱替換而不對Texinfo手冊進行替換。

設定站點缺省值
Autoconf生成的configure腳本允許你的站點（site）為某些配置值提供缺省值。你可以透過創建站點範圍（site-wide）或者系統範圍（system-wide）的初始化檔案來達到這個目的。

如果設定了環境變量CONFIG_SITE,configure就把它的值作為讀入的shell腳本的名稱。否則如果``prefix/share/config.site''存在,它就讀入該腳本,否則如果``prefix/etc/config.site''存在,它就讀入該腳本。因此,如果出現衝突,在機器特定檔案中的設定將覆蓋那些與機器獨立的檔案中的設定。

站點檔案（site files）可以是任意shell腳本,但只能包含某種適於包含在其中的代碼。因為configure在它讀入所有站點檔案之後讀取任何緩存檔案,站點檔案可以定義一個缺省的緩存檔案以便在本系統中營運的所有Autoconf生成的 configure之間共享。如果你在站點檔案中設定了缺省緩存檔案,那麼再在那個站點檔案中設定輸出變量 CC就是個好主意,這是因為緩存檔案僅僅對特定的編譯器來說是合法的,但許多系統還有好幾個可用的編譯器。

你可以在站點檔案中檢驗或者覆蓋由命令行選項設定的值；與選項對應的shell變量的名稱與選項的名字的唯一區別是選項名中所有的破折號應變換成的下劃線。選項``--without-''和``--disable-''是個例外,出現它們就如同出現對應的 ``--with-''或者``--enable-''並且把值設定為``no''。因此, ``--cache-file=localcache''把變量cache_file的值設定為``localcache''； ``--enable-warnings=no''或者``--disable-warnings''把變量enable_warnings 的值設定為``no''；``--prefix=/usr''把變量prefix設定為``/usr''；等等。

如果你需要為其它輸出變量設定與缺省值不同的值（你通常不得不在命令行中重複地進行設定）,比如說CFLAGS,站點檔案就是進行這種設定的好地方。如果你為prefix或者exec_prefix設定了非缺省值（你放置站點檔案的地方）,如果你用環境變量CONFIG_SITE給出了站點檔案,你就可以在站點檔案中設定這些非缺省值。

你可以在站點檔案中設定一些緩存值。如果你正在進行交叉編譯,這樣做就是有用的,以避免對需要營運測試程式的特徵進行檢查。你可以為``prefix/etc/config.site''中的系統正確地設定這些值來“預備緩存（prime cache）”。為了找到你要設定的緩存變量名,可以在受到影響的configure腳本中尋找帶有``_cv_''的shell變量,也可以在Autoconf m4源代碼中尋找這些宏。

緩存檔案將十分謹慎而不至於覆蓋任何在站點檔案中設定的變量。類似地,你不應該在站點檔案中覆蓋命令行選項。你的代碼應該在修改諸如prefix和cache_file的變量之前,檢查它們的缺省值（就是在靠近configure開頭的地方設定的值）。

下面是一個例子檔案``/usr/share/local/gnu/share/config.site''。（如果沒有把CONFIG_SITE設定成其它檔案,）命令``configure --prefix=/usr/share/local/gnu'' 將讀入該檔案。

# config.site for configure
# Change some defaults.
test ""$prefix"" = NONE && prefix=/usr/share/local/gnu
test ""$exec_prefix"" = NONE && exec_prefix=/usr/local/gnu
test ""$sharedstatedir"" = ''${prefix}/com'' && sharedstatedir=/var
test ""$localstatedir"" = ''${prefix}/var'' && localstatedir=/var
#
# Give Autoconf 2.x generated configure scripts a shared default
# cache file for feature test results,architecture-specific.
if test ""$cache_file"" = ./config.cache; then
cache_file=""$prefix/var/config.cache""
# A cache file is only valid for one C compiler.
CC=gcc
fi

營運configure腳本
下面是關於如何配置使用configure腳本的套裝軟件的說明,適用於包中的``INSTALL''檔案。你可能要使用的普通文本的``INSTALL''與Autoconf一同發行。

重新創建一個配置
configure腳本創建一個名為``config.status''的檔案,用它描述在包最後一次進行配置時給出的配置選項。該檔案是一個shell腳本檔案,如果營運它,將重新創建相同的配置。
你可以用``--recheck''選項調用``config.status''以更新它自身。如果你修改了configure,該選項是有用的,這是因為某些測試的結果可能會與上一次營運的結果不同。選項``--recheck''以與從前使用的參數相同的參數,再加上``--no-create''選項以防止configure營運``config.status''並創建 ``Makefile''和其它檔案,再加上``--no-recursion''選項以防止configure在次目錄中營運其它的configure,來重新營運configure。（這樣做是讓其它的``Makefile''規則可以在 ``config.status''改變時營運它；關於一個例子,參見自動地重新創建）。
``config.status''還接受選項``--help'',它列印``config.status''接受的選項的概述。還接受選項``--version'',它列印用於創建生成``config.status''的configure腳本的 Autoconf的版本號。
``config.status''檢查幾個能夠改變它的行為的可選的環境變量︰
變量︰ CONFIG_SHELL
用於營運帶有``--recheck''選項的configure的腳本。它必須是Bourne兼容的。缺省shell是``/bin/sh''。
變量︰ CONFIG_STATUS
為shell腳本提供的,用於記錄配置的檔案名。缺省的檔案名是``./config.status''。該變量在一個包使用了另一個包的一部分,並且由於兩個包是分開維護的而不能把configure合成一個的時候有用。

以下的變量為分開發布的包提供了一種共享由configure計算的結果的模式。如果某些包需要它們中某個包,可能是一個通用庫,所需要的特徵的超集那麼這樣做就是有用的。這些變量允許一個``config.status''檔案創建由它的``configure.in''所指明的檔案之外的檔案,因此它就可以被用於不同的包。
變量︰ CONFIG_FILES
用於執行``@variable@''替換的檔案。缺省的檔案在``configure.in''中作為參數提供給 AC_OUTPUT。
變量︰ CONFIG_HEADERS
用於替換C #define語句的檔案。缺省的檔案作為參數提供給AC_CONFIG_HEADER；如果沒有調用那個宏,``config.status''就忽略本變量。

這些變量還允許你編寫只重新生成一部分檔案的``Makefile''規則。例如,在上面給出的倚賴性之中（參見自動地重新創建）,在``configure.in''發生改變時, ``config.status''將營運兩次。如果你對此感到厭煩,你可以使得每次營運都僅僅重新生成關於那條規則的檔案。

config.h: stamp-h
stamp-h: config.h.in config.status
CONFIG_FILES= CONFIG_HEADERS=config.h ./config.status
echo > stamp-h

Makefile: Makefile.in config.status
CONFIG_FILES=Makefile CONFIG_HEADERS= ./config.status

(如果``configure.in''並不調用AC_CONFIG_HEADER,就不必在make規則中設定 CONFIG_HEADERS。)
關於Autoconf的問題
有時我們會遇到幾個關於Autoconf的問題。下面是被提及的一些問題。

發布configure腳本
對發行由Autoconf生成的configure有什麼限制？它們是如何影響我那些使用它們的程式的？

關於由Autoconf生成的配置腳本是如何發行和如何被使用的,並沒有限制。在Autoconf第1版中,它們是服從GNU通用公共許可證的。我們仍然鼓勵軟體的作者按照諸如GPL的條款發行他們的作品,但Autoconf並不要求這樣做。

關於可能由configure使用的其它檔案,``config.h.in''服從你為你的``configure.in''而使用的任何版權規定,這是因為它是從那個檔案和公有檔案``acconfig.h''中派生出來的。當``config.sub''和 ``config.guess''被用於由Autoconf生成的、允許你按照與你的套裝軟件其它部分相同的條款發布的configure 腳本中時,它們就是GPL的一個例外。``install-sh''是來自於X Consortium並且是沒有版權的。

為什麼需要使用GNU m4?
為什麼Autoconf需要使用GNU m4？
許多m4的實現含有編碼性（hard-coded）的,對宏的大小和數量的限制,Autoconf超過了這些限制。它們還缺少一些內置宏,沒有它們,諸如Autoconf之類的複雜應用程式將難以應付,它們包括︰
builtin
indir
patsubst
__file__
__line__
因為只有軟體維護者需要使用Autoconf,並且因為GNU m4易於配置和安裝,需要安裝GNU m4 好像是合理的。許多GNU和其它自由軟體的維護者,因為他們更喜愛GNU工具,都已經安裝了大部分GNU工具。