獲取規範的系統類型
下列的宏是的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-readlinesupport 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 myprog|sed '$(transform)'`
uninstall:
rm -f $(bindir)/`echo myprog|sed '$(transform)'`
如果你要安裝多個程序,你可以通過一個循環來完成：
PROGRAMS=cp ls rm
install:
for p in $(PROGRAMS); do
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`;
done
uninstall:
for p in $(PROGRAMS); do
rm -f $(bindir)/`echo $$p|sed '$(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工具.
