Creating Automatic Configuration Scripts
Edition 2.13, for Autoconf version 2.13
December 1998
by David MacKenzie and Ben Elliston
--------------------------------------------------------------------------------
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation.
只要版權聲明和本許可聲明保留在所有副本中，您就被授權制作和發行本手冊的原文副本。
只要整個最終派生工作按照與本手冊相同的許可聲明發行，您就被授權按照與發行原文相同的條件複製和發行本手冊的修改版本。
除了本許可聲明應該使用由基金會批准的譯文之外，您被授權按照與上述修改版本相同的條件複製和發行本手冊的其它語言的譯文。
--------------------------------------------------------------------------------
本文檔由王立翻譯。 1999.12.16
譯者在此聲明：不對任何由譯文錯誤或者對譯文的誤解承擔任何責任。
--------------------------------------------------------------------------------
介紹
A physicist, an engineer, and a computer scientist were
discussing the nature of God. Surely a Physicist, said the
physicist, because early in the Creation, God made Light; and you
know, Maxwell's equations, the dual nature of electro-magnetic
waves, the relativist consequences... An Engineer!, said the
engineer, because before making Light, God split the Chaos into
Land and Water; it takes a hell of an engineer to handle that big
amount of mud, and orderly separation of solids from
liquids... The computer scientist shouted: And the Chaos,
where do you think it was coming from, hmm?
---Anonymous
Autoconf是一個用於生成可以自動地配置軟件源代碼包以適應多種Unix類系統的 shell腳本的工具。由Autoconf生成的配置腳本在運行的時候與Autoconf是無關的，就是說配置腳本的用戶並不需要擁有Autoconf。
由Autoconf生成的配置腳本在運行的時候不需要用戶的手工干預；通常它們甚至不需要通過給出參數以確定系統的類型。相反，它們對軟件包可能需要的各種特徵進行獨立的測試。（在每個測試之前，它們打印一個單行的消息以說明它們正在進行的檢測，以使得用戶不會因爲等待腳本執行完畢而焦躁。）因此，它們在混合系統或者從各種常見Unix變種定製而成的系統中工作的很好。沒有必要維護文件以儲存由各個Unix變種、各個發行版本所支持的特徵的列表。
對於每個使用了Autoconf的軟件包，Autoconf從一個列舉了該軟件包需要的，或者可以使用的系統特徵的列表的模板文件中生成配置腳本。在shell代碼識別並響應了一個被列出的系統特徵之後，Autoconf允許多個可能使用（或者需要）該特徵的軟件包共享該特徵。如果後來因爲某些原因需要調整shell代碼，就只要在一個地方進行修改；所有的配置腳本都將被自動地重新生成以使用更新了的代碼。
Metaconfig包在目的上與Autoconf很相似，但它生成的腳本需要用戶的手工干預，在配置一個大的源代碼樹的時候這是十分不方便的。不象Metaconfig腳本，如果在編寫腳本時小心謹慎， Autoconf可以支持交叉編譯（cross-compiling）。
Autoconf目前還不能完成幾項使軟件包可移植的工作。其中包括爲所有標準的目標自動創建`Makefile'文件，包括在缺少標準庫函數和頭文件的系統上提供替代品。目前正在爲在將來添加這些特徵而工作。
對於在C程序 中的#ifdef中使用的宏的名字，Autoconf施加了一些限制（參見預處理器符號索引）。
Autoconf需要GNU m4以便於生成腳本。它使用了某些UNIX版本的m4 所不支持的特徵。它還會超出包括GNU m4 1.0在內的某些m4版本的內部限制。你必須使用GNU m4的1.1版或者更新的版本。使用1.3版或者更新的版本將比1.1 或1.2版快許多。
關於從版本1中升級的詳情，參見從版本1中升級。關於Autoconf的開發歷史，參見Autoconf的歷史。對與Autoconf有關的常見問題的回答，參見關於Autoconf的問題。
把關於Autoconf的建議和bug報告發送到[email][email protected][/email]。請把你通過運行`autoconf --version'而獲得的Autoconf的版本號包括在內。
創建configure腳本
由Autoconf生成的配置腳本通常被稱爲configure。在運行的時候，configure 創建一些文件，在這些文件中以適當的值替換配置參數。由configure創建的文件有：
一個或者多個`Makefile'文件，在包的每個子目錄中都有一個（參見 Makefile中的替換）；
有時創建一個C頭文件，它的名字可以被配置，該頭文件包含一些#define命令（參見配置頭文件）；
一個名爲`config.status'的shell腳本，在運行時，它將重新創建上述文件。（參見重新創建一個配置）；
一個名爲`config.cache'的shell腳本，它儲存了許多測試的運行結果（參見緩存文件）；
一個名爲`config.log'的文件，它包含了由編譯器生成的許多消息，以便於在configure出現錯誤時進行調試。
爲了使用Autoconf創建一個configure腳本，你需要編寫一個Autoconf的輸入文件 `configure.in'並且對它運行autoconf。如果你自行編寫了特徵測試以補充 Autoconf所提供的測試，你可能還要編寫一個名爲`aclocal.m4'的文件和一個名爲 `acsite.m4'的文件。如果你使用了包含#define指令的C頭文件，你可能還要編寫`acconfig.h'，並且你需要與軟件包一同發佈由Autoconf生成的文件 `config.h.in'。
下面是一個說明了在配置中使用的文件是如何生成的圖。運行的程序都標以後綴`*'。可能出現的文件被方括號(`[]')括起來。autoconf和autoheader 還讀取安裝了的Autoconf宏文件（通過讀取`autoconf.m4'）。
在準備發佈軟件包的過程中使用的文件：
你的源文件 --> [autoscan*] --> [configure.scan] --> configure.in
configure.in --. .------> autoconf* -----> configure
+---+
[aclocal.m4] --+ `---.
[acsite.m4] ---' |
+--> [autoheader*] -> [config.h.in]
[acconfig.h] ----. |
+-----'
[config.h.top] --+
[config.h.bot] --'
Makefile.in -------------------------------> Makefile.in
在配置軟件包的過程中使用的文件：
.-------------> config.cache
configure* ------------+-------------> config.log
|
[config.h.in] -. v .-> [config.h] -.
+--> config.status* -+ +--> make*
Makefile.in ---' `-> Makefile ---'
編寫`configure.in'
爲了爲軟件包創建configure腳本，需要編寫一個名爲`configure.in' 的文件，該文件包含了對那些你的軟件包需要或者可以使用的系統特徵進行測試的Autoconf宏的調用。現有的Autoconf宏可以檢測許多特徵； 對於它們的描述可以參見現有的測試。對於大部分其他特徵，你可以使用Autconf模板宏以創建定製的測試；關於它們的詳情，參見 編寫測試。對於特別古怪或者特殊的特徵，`configure.in' 可能需要包含一些手工編寫的shell命令。程序autoscan可以爲你編寫`configure.in' 開個好頭（詳情請參見用autoscan創建`configure.in'）。
除了少數特殊情況之外，在`configure.in'中調用Autoconf宏的順序並不重要。在每個`configure.in'中，必須在進行任何測試之間包含一個對AC_INIT的調用，並且在結尾處包含一個對AC_OUTPUT的調用（參見創建輸出文件）。此外，有些宏要求其他的宏在它們之前被調用，這是因爲它們通過檢查某些變量在前面設定的值以決定作些什麼。這些宏在獨立的說明中給出（參見現有的測試），而且如果沒有按照順序調用宏，在生成configure時會向你發出警告。
爲了提高一致性，下面是調用Autoconf宏的推薦 順序。通常，在本列表中靠後的項目依賴於表中靠前的項目。例如，庫函數可能受到typedefs和庫的影響。
AC_INIT(file)
checks for programs
checks for libraries
checks for header files
checks for typedefs
checks for structures
checks for compiler characteristics
checks for library functions
checks for system services
AC_OUTPUT([file...])
最好讓每個宏調用在`configure.in'中佔據單獨的一行。大部分宏並不添加額外的新行；它們依賴於在宏調用之後的新行以結束命令。這種方法使得生成的configure腳本在不必添加大量的空行的情況下比較容易閱讀。在宏調用的同一行中設置shell變量通常是安全的，這是因爲shell允許出現沒有用新行間隔的賦值。
在調用帶參數的宏的時候，在宏名和左括號之間不能出現任何空格。如果參數被m4 引用字符`['和`]'所包含，參數就可以多於一行。如果你有一個長行，比如說一個文件名列表，你通常可以在行的結尾使用反斜線以便在邏輯上把它與下一行進行連接（這是由shell實現的，Autoconf對此沒有進行任何特殊的處理）。
有些宏處理兩種情況：如果滿足了某個給定的條件就做什麼，如果沒有滿足某個給定的條件就做什麼。在有些地方，你可能希望在條件爲真的情況下作些事，在爲假時什麼也不作。反之亦然。爲了忽略爲真的情況，把空值作爲參數action-if-found傳遞給宏。爲了忽略爲假的情況，可以忽略包括前面的逗號在內的宏的參數action-if-not-found。
你可以在文件`configure.in'中添加註釋。註釋以m4預定義宏dnl 開頭，該宏丟棄在下一個新行之前的所有文本。這些註釋並不在生成的configure腳本中出現。例如，把下面給出的行作爲文件`configure.in'的開頭是有好處的：
dnl Process this file with autoconf to produce a configure script.
用autoscan創建`configure.in'
程序autoscan可以幫助你爲軟件包創建`configure.in'文件。如果在命令行中給出了目錄， autoscan就在給定目錄及其子目錄樹中檢查源文件，如果沒有給出目錄，就在當前目錄及其子目錄樹中進行檢查。它搜索源文件以尋找一般的移植性問題並創建一個文件`configure.scan'，該文件就是軟件包的`configure.in'預備版本。
在把`configure.scan'改名爲`configure.in'之前，你應該手工地檢查它；它可能需要一些調整。 autoscan偶爾會按照相對於其他宏的錯誤的順序輸出宏，爲此autoconf將給出警告；你需要手工地移動這些宏。還有，如果你希望包使用一個配置頭文件，你必須添加一個對AC_CONFIG_HEADER的調用。（參見配置頭文件）。可能你還必須在你的程序中修改或者添加一些#if 指令以使得程序可以與Autoconf合作。（關於有助於該工作的程序的詳情，參見 用ifnames列舉條件）。
autoscan使用一些數據文件，它們是隨發佈的Autoconf宏文件一起安裝的，以便當它在包中的源文件中發現某些特殊符號時決定輸出那些宏。這些文件都具有相同的格式。每一個都是由符號、空白和在符號出現時應該輸出的Autoconf 宏。以`#'開頭的行是註釋。
只有在你安裝了Perl的情況下才安裝autoscan。 autoscan接受如下選項：
--help
打印命令行選項的概述並且退出。
--macrodir=dir
在目錄dir中，而不是在缺省安裝目錄中尋找數據文件。你還可以把環境變量AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--verbose
打印它檢查的文件名稱以及在這些文件中發現的可能感興趣的符號。它的輸出可能很冗長。
--version
打印Autoconf的版本號並且退出。
用ifnames列舉條件
在爲一個軟件包編寫`configure.in'時，ifnames可以提供一些幫助。它打印出包已經在C預處理條件中使用的標識符。如果包已經被設置得具備了某些可移植性，該程序可以幫助你找到configure所需要進行的檢查。它可能有助於補足由autoscan生成的`configure.in'中的某些缺陷。（參見用autoscan創建`configure.in'）。
ifnames掃描所有在命令行中給出的C源代碼文件（如果沒有給出，就掃描標準輸入）並且把排序後的、由所有出現在這些文件中的#if、#elif、#ifdef或者#ifndef 命令中的標識符列表輸出到標準輸出中。它爲每個標識符輸出單獨的一行，行中標識符之後是一個由空格分隔的、使用了該標識符的文件名列表。
ifnames接受如下選項：
--help
-h
打印命令行選項的概述並且退出。
--macrodir=dir
-m dir
在目錄dir中，而不是缺省安裝目錄中尋找Autoconf宏文件。僅僅被用於獲取版本號。你還可以把環境變量AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--version
打印Autoconf的版本號並且退出。
用autoconf創建configure
爲了從`configure.in'生成configure，不帶參數地運行程序autoconf。 autoconf用使用Autoconf宏的m4宏處理器處理`configure.in'。如果你爲autoconf提供了參數，它讀入給出的文件而不是`configure.in'並且把配置腳本輸出到標準輸出而不是configure。如果你給autoconf以參數`-'，它將從標準輸入，而不是`configure.in'中讀取並且把配置腳本輸出到標準輸出。
Autoconf宏在幾個文件中定義。在這些文件中，有些是與Autconf一同發佈的；autoconf首先讀入它們。而後它在包含了發佈的Autoconf宏文件的目錄中尋找可能出現的文件`acsite.m4'，並且在當前目錄中尋找可能出現的文件`aclocal.m4'。這些文件可以包含你的站點的或者包自帶的Autoconf宏定義（詳情請參見 編寫宏）。如果宏在多於一個由autoconf讀入了的文件中被定義，那麼後面的定義將覆蓋前面的定義。
autoconf接受如下參數：
--help
-h
輸出命令行選項的概述並且退出。
--localdir=dir
-l dir
在目錄dir中，而不是當前目錄中尋找包文件`aclocal.m4'。
--macrodir=dir
-m dir
在目錄dir中尋找安裝的宏文件。你還可以把環境變量AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--version
打印Autoconf的版本號並且退出。
用autoreconf更新configure腳本
如果你有大量由Autoconf生成的configure腳本，程序autoreconf可以保留你的一些工作。它重複地運行autoconf（在適當的情況下還運行autoheader）以重新創建以當前目錄爲根的目錄樹的Autoconf configure腳本和配置頭文件。在缺省情況下，它只重新創建那些比對應的 `configure.in'或者（如果出現）`aclocal.m4'要舊的文件。由於在文件沒有被改變的情況下， autoheader並不改變它的輸出文件的時間標記（timestamp）。這是爲了使工作量最小化，修改時間標記是不必要的。如果你安裝了新版本的Autoconf，你可以以選項`--force'調用autoreconf而重新創建 所有的文件。
如果你在調用autoreconf時給出選項`--macrodir=dir'或者 `--localdir=dir'，它將把它們傳遞給autoconf和autoheader （相對路徑將被正確地調整）。
在同一個目錄樹中，autoreconf不支持兩個目錄作爲同一個大包的一部分（共享`aclocal.m4'和 `acconfig.h'），也不支持每個目錄都是獨立包（每個目錄都有它們自己的`aclocal.m4'和 `acconfig.h'）。如果你使用了`--localdir'，它假定所有的目錄都是同一個包的一部分。如果你沒有使用 `--localdir'，它假定每個目錄都是一個獨立的包，這條限制在將來可能被取消。
關於在configure腳本的源文件發生變化的情況下自動地重新創建它們的`Makefile'規則的細節，參見自動地重新創建。這種方法正確地處理了配置頭文件模板的時間標記，但並不傳遞`--macrodir=dir'或者`--localdir=dir'。
autoreconf接受如下選項：
--help
-h
打印命令行選項的概述並且退出。
--force
-f
即使在`configure'腳本和配置頭文件比它們的輸入文件（`configure.in'，如果出現了`aclocal.m4'，也包括它）更新的時候，也要重新創建它們。
--localdir=dir
-l dir
讓autoconf和autoheader在目錄dir中，而不是在每個包含`configure.in' 的目錄中尋找包文件`aclocal.m4'和（僅指autoheader）`acconfig.h' （但不包括`file.top'和`file.bot'）。
--macrodir=dir
-m dir
在目錄dir中，而不是缺省安裝目錄中尋找Autoconf宏文件。你還可以把環境變量 AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--verbose
打印autoreconf運行autoconf（如果適當，還有autoheader）的每個目錄的目錄名。
--version
打印Autoconf的版本號並且退出。
初始化和輸出文件
Autoconf生成的configure腳本需要一些關於如何進行初始化，諸如如何尋找包的源文件，的信息；以及如何生成輸出文件的信息。本節敘述如何進行初始化和創建輸出文件。
尋找configure的輸入文件
所有configure腳本在作任何其他事情之前都必須調用AC_INIT。此外唯一必須調用的宏是 AC_OUTPUT（參見創建輸出文件）。
宏： AC_INIT (unique-file-in-source-dir)
處理所有命令行參數並且尋找源代碼目錄。unique-file-in-source-dir是一些在包的源代碼目錄中文件； configure在目錄中檢查這些文件是否存在以確定該目錄是否包含源代碼。人們可能偶爾會用`--srcdir'給出錯誤的目錄；這是一種安全性檢查。詳情請參見運行configure腳本。
對於需要手工配置或者使用install程序的包來說，雖然在缺省源代碼位置在大部分情況下看起來是正確的，包還是可能需要通過調用AC_CONFIG_AUX_DIR來告訴 configure到那裏去尋找一些其他的shell腳本。
宏： AC_CONFIG_AUX_DIR (dir)
在目錄dir中使用`install-sh'、`config.sub'、`config.guess'和 Cygnus configure配置腳本。它們是配置中使用的輔助文件。dir既可以是絕對路徑，也可以是相對於`srcdir'的相對路徑。缺省值是在`srcdir'或者 `srcdir/..'或者`srcdir/../..'中首先找到`install-sh' 的目錄。不對其他文件進行檢查，以便使AC_PROG_INSTALL不會自動地發佈其他輔助文件。它還要檢查`install.sh'，但因爲有些make程序包含了在沒有`Makefile'的情況下從`install.sh'中創建`install'的規則，所以那個名字過時了。
創建輸出文件
每個Autoconf生成的configure腳本必須以對AC_OUTPUT的調用結尾。它是一個創建作爲配置結果的`Makefile'以及其他一些可能的文件的宏。此外唯一必須調用的宏是AC_INIT （參見尋找configure的輸入文件）。
宏： AC_OUTPUT ([file... [, extra-cmds [, init-cmds]]])
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation.
只要版權聲明和本許可聲明保留在所有副本中，您就被授權制作和發行本手冊的原文副本。
只要整個最終派生工作按照與本手冊相同的許可聲明發行，您就被授權按照與發行原文相同的條件複製和發行本手冊的修改版本。
除了本許可聲明應該使用由基金會批准的譯文之外，您被授權按照與上述修改版本相同的條件複製和發行本手冊的其它語言的譯文。
--------------------------------------------------------------------------------
本文檔由王立翻譯。 1999.12.16
譯者在此聲明：不對任何由譯文錯誤或者對譯文的誤解承擔任何責任。
--------------------------------------------------------------------------------
介紹
A physicist, an engineer, and a computer scientist were
discussing the nature of God. Surely a Physicist, said the
physicist, because early in the Creation, God made Light; and you
know, Maxwell's equations, the dual nature of electro-magnetic
waves, the relativist consequences... An Engineer!, said the
engineer, because before making Light, God split the Chaos into
Land and Water; it takes a hell of an engineer to handle that big
amount of mud, and orderly separation of solids from
liquids... The computer scientist shouted: And the Chaos,
where do you think it was coming from, hmm?
---Anonymous
Autoconf是一個用於生成可以自動地配置軟件源代碼包以適應多種Unix類系統的 shell腳本的工具。由Autoconf生成的配置腳本在運行的時候與Autoconf是無關的，就是說配置腳本的用戶並不需要擁有Autoconf。
由Autoconf生成的配置腳本在運行的時候不需要用戶的手工干預；通常它們甚至不需要通過給出參數以確定系統的類型。相反，它們對軟件包可能需要的各種特徵進行獨立的測試。（在每個測試之前，它們打印一個單行的消息以說明它們正在進行的檢測，以使得用戶不會因爲等待腳本執行完畢而焦躁。）因此，它們在混合系統或者從各種常見Unix變種定製而成的系統中工作的很好。沒有必要維護文件以儲存由各個Unix變種、各個發行版本所支持的特徵的列表。
對於每個使用了Autoconf的軟件包，Autoconf從一個列舉了該軟件包需要的，或者可以使用的系統特徵的列表的模板文件中生成配置腳本。在shell代碼識別並響應了一個被列出的系統特徵之後，Autoconf允許多個可能使用（或者需要）該特徵的軟件包共享該特徵。如果後來因爲某些原因需要調整shell代碼，就只要在一個地方進行修改；所有的配置腳本都將被自動地重新生成以使用更新了的代碼。
Metaconfig包在目的上與Autoconf很相似，但它生成的腳本需要用戶的手工干預，在配置一個大的源代碼樹的時候這是十分不方便的。不象Metaconfig腳本，如果在編寫腳本時小心謹慎， Autoconf可以支持交叉編譯（cross-compiling）。
Autoconf目前還不能完成幾項使軟件包可移植的工作。其中包括爲所有標準的目標自動創建`Makefile'文件，包括在缺少標準庫函數和頭文件的系統上提供替代品。目前正在爲在將來添加這些特徵而工作。
Autoconf需要GNU m4以便於生成腳本。它使用了某些UNIX版本的m4 所不支持的特徵。它還會超出包括GNU m4 1.0在內的某些m4版本的內部限制。你必須使用GNU m4的1.1版或者更新的版本。使用1.3版或者更新的版本將比1.1 或1.2版快許多。
關於從版本1中升級的詳情，參見從版本1中升級。關於Autoconf的開發歷史，參見Autoconf的歷史。對與Autoconf有關的常見問題的回答，參見關於Autoconf的問題。
把關於Autoconf的建議和bug報告發送到[email][email protected][/email]。請把你通過運行`autoconf --version'而獲得的Autoconf的版本號包括在內。
創建configure腳本
由Autoconf生成的配置腳本通常被稱爲configure。在運行的時候，configure 創建一些文件，在這些文件中以適當的值替換配置參數。由configure創建的文件有：
一個或者多個`Makefile'文件，在包的每個子目錄中都有一個（參見 Makefile中的替換）；
有時創建一個C頭文件，它的名字可以被配置，該頭文件包含一些#define命令（參見配置頭文件）；
一個名爲`config.status'的shell腳本，在運行時，它將重新創建上述文件。（參見重新創建一個配置）；
一個名爲`config.cache'的shell腳本，它儲存了許多測試的運行結果（參見緩存文件）；
一個名爲`config.log'的文件，它包含了由編譯器生成的許多消息，以便於在configure出現錯誤時進行調試。
爲了使用Autoconf創建一個configure腳本，你需要編寫一個Autoconf的輸入文件 `configure.in'並且對它運行autoconf。如果你自行編寫了特徵測試以補充 Autoconf所提供的測試，你可能還要編寫一個名爲`aclocal.m4'的文件和一個名爲 `acsite.m4'的文件。如果你使用了包含#define指令的C頭文件，你可能還要編寫`acconfig.h'，並且你需要與軟件包一同發佈由Autoconf生成的文件 `config.h.in'。
下面是一個說明了在配置中使用的文件是如何生成的圖。運行的程序都標以後綴`*'。可能出現的文件被方括號(`[]')括起來。autoconf和autoheader 還讀取安裝了的Autoconf宏文件（通過讀取`autoconf.m4'）。
在準備發佈軟件包的過程中使用的文件：
你的源文件 --> [autoscan*] --> [configure.scan] --> configure.in
configure.in --. .------> autoconf* -----> configure
+---+
[aclocal.m4] --+ `---.
[acsite.m4] ---' |
+--> [autoheader*] -> [config.h.in]
[acconfig.h] ----. |
+-----'
[config.h.top] --+
[config.h.bot] --'
Makefile.in -------------------------------> Makefile.in
在配置軟件包的過程中使用的文件：
.-------------> config.cache
configure* ------------+-------------> config.log
|
[config.h.in] -. v .-> [config.h] -.
+--> config.status* -+ +--> make*
Makefile.in ---' `-> Makefile ---'
編寫`configure.in'
爲了爲軟件包創建configure腳本，需要編寫一個名爲`configure.in' 的文件，該文件包含了對那些你的軟件包需要或者可以使用的系統特徵進行測試的Autoconf宏的調用。現有的Autoconf宏可以檢測許多特徵； 對於它們的描述可以參見現有的測試。對於大部分其他特徵，你可以使用Autconf模板宏以創建定製的測試；關於它們的詳情，參見 編寫測試。對於特別古怪或者特殊的特徵，`configure.in' 可能需要包含一些手工編寫的shell命令。程序autoscan可以爲你編寫`configure.in' 開個好頭（詳情請參見用autoscan創建`configure.in'）。
除了少數特殊情況之外，在`configure.in'中調用Autoconf宏的順序並不重要。在每個`configure.in'中，必須在進行任何測試之間包含一個對AC_INIT的調用，並且在結尾處包含一個對AC_OUTPUT的調用（參見創建輸出文件）。此外，有些宏要求其他的宏在它們之前被調用，這是因爲它們通過檢查某些變量在前面設定的值以決定作些什麼。這些宏在獨立的說明中給出（參見現有的測試），而且如果沒有按照順序調用宏，在生成configure時會向你發出警告。
AC_INIT(file)
checks for programs
checks for libraries
checks for header files
checks for typedefs
checks for structures
checks for compiler characteristics
checks for library functions
checks for system services
AC_OUTPUT([file...])
最好讓每個宏調用在`configure.in'中佔據單獨的一行。大部分宏並不添加額外的新行；它們依賴於在宏調用之後的新行以結束命令。這種方法使得生成的configure腳本在不必添加大量的空行的情況下比較容易閱讀。在宏調用的同一行中設置shell變量通常是安全的，這是因爲shell允許出現沒有用新行間隔的賦值。
在調用帶參數的宏的時候，在宏名和左括號之間不能出現任何空格。如果參數被m4 引用字符`['和`]'所包含，參數就可以多於一行。如果你有一個長行，比如說一個文件名列表，你通常可以在行的結尾使用反斜線以便在邏輯上把它與下一行進行連接（這是由shell實現的，Autoconf對此沒有進行任何特殊的處理）。
有些宏處理兩種情況：如果滿足了某個給定的條件就做什麼，如果沒有滿足某個給定的條件就做什麼。在有些地方，你可能希望在條件爲真的情況下作些事，在爲假時什麼也不作。反之亦然。爲了忽略爲真的情況，把空值作爲參數action-if-found傳遞給宏。爲了忽略爲假的情況，可以忽略包括前面的逗號在內的宏的參數action-if-not-found。
你可以在文件`configure.in'中添加註釋。註釋以m4預定義宏dnl 開頭，該宏丟棄在下一個新行之前的所有文本。這些註釋並不在生成的configure腳本中出現。例如，把下面給出的行作爲文件`configure.in'的開頭是有好處的：
dnl Process this file with autoconf to produce a configure script.
用autoscan創建`configure.in'
程序autoscan可以幫助你爲軟件包創建`configure.in'文件。如果在命令行中給出了目錄， autoscan就在給定目錄及其子目錄樹中檢查源文件，如果沒有給出目錄，就在當前目錄及其子目錄樹中進行檢查。它搜索源文件以尋找一般的移植性問題並創建一個文件`configure.scan'，該文件就是軟件包的`configure.in'預備版本。
在把`configure.scan'改名爲`configure.in'之前，你應該手工地檢查它；它可能需要一些調整。 autoscan偶爾會按照相對於其他宏的錯誤的順序輸出宏，爲此autoconf將給出警告；你需要手工地移動這些宏。還有，如果你希望包使用一個配置頭文件，你必須添加一個對AC_CONFIG_HEADER的調用。（參見配置頭文件）。可能你還必須在你的程序中修改或者添加一些#if 指令以使得程序可以與Autoconf合作。（關於有助於該工作的程序的詳情，參見 用ifnames列舉條件）。
autoscan使用一些數據文件，它們是隨發佈的Autoconf宏文件一起安裝的，以便當它在包中的源文件中發現某些特殊符號時決定輸出那些宏。這些文件都具有相同的格式。每一個都是由符號、空白和在符號出現時應該輸出的Autoconf 宏。以`#'開頭的行是註釋。
只有在你安裝了Perl的情況下才安裝autoscan。 autoscan接受如下選項：
--help
打印命令行選項的概述並且退出。
--macrodir=dir
在目錄dir中，而不是在缺省安裝目錄中尋找數據文件。你還可以把環境變量AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--verbose
打印它檢查的文件名稱以及在這些文件中發現的可能感興趣的符號。它的輸出可能很冗長。
--version
打印Autoconf的版本號並且退出。
用ifnames列舉條件
在爲一個軟件包編寫`configure.in'時，ifnames可以提供一些幫助。它打印出包已經在C預處理條件中使用的標識符。如果包已經被設置得具備了某些可移植性，該程序可以幫助你找到configure所需要進行的檢查。它可能有助於補足由autoscan生成的`configure.in'中的某些缺陷。（參見用autoscan創建`configure.in'）。
ifnames掃描所有在命令行中給出的C源代碼文件（如果沒有給出，就掃描標準輸入）並且把排序後的、由所有出現在這些文件中的#if、#elif、#ifdef或者#ifndef 命令中的標識符列表輸出到標準輸出中。它爲每個標識符輸出單獨的一行，行中標識符之後是一個由空格分隔的、使用了該標識符的文件名列表。
ifnames接受如下選項：
--help
-h
打印命令行選項的概述並且退出。
--macrodir=dir
-m dir
在目錄dir中，而不是缺省安裝目錄中尋找Autoconf宏文件。僅僅被用於獲取版本號。你還可以把環境變量AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--version
打印Autoconf的版本號並且退出。
用autoconf創建configure
爲了從`configure.in'生成configure，不帶參數地運行程序autoconf。 autoconf用使用Autoconf宏的m4宏處理器處理`configure.in'。如果你爲autoconf提供了參數，它讀入給出的文件而不是`configure.in'並且把配置腳本輸出到標準輸出而不是configure。如果你給autoconf以參數`-'，它將從標準輸入，而不是`configure.in'中讀取並且把配置腳本輸出到標準輸出。
Autoconf宏在幾個文件中定義。在這些文件中，有些是與Autconf一同發佈的；autoconf首先讀入它們。而後它在包含了發佈的Autoconf宏文件的目錄中尋找可能出現的文件`acsite.m4'，並且在當前目錄中尋找可能出現的文件`aclocal.m4'。這些文件可以包含你的站點的或者包自帶的Autoconf宏定義（詳情請參見 編寫宏）。如果宏在多於一個由autoconf讀入了的文件中被定義，那麼後面的定義將覆蓋前面的定義。
autoconf接受如下參數：
--help
-h
輸出命令行選項的概述並且退出。
--localdir=dir
-l dir
在目錄dir中，而不是當前目錄中尋找包文件`aclocal.m4'。
--macrodir=dir
-m dir
在目錄dir中尋找安裝的宏文件。你還可以把環境變量AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--version
打印Autoconf的版本號並且退出。
用autoreconf更新configure腳本
如果你有大量由Autoconf生成的configure腳本，程序autoreconf可以保留你的一些工作。它重複地運行autoconf（在適當的情況下還運行autoheader）以重新創建以當前目錄爲根的目錄樹的Autoconf configure腳本和配置頭文件。在缺省情況下，它只重新創建那些比對應的 `configure.in'或者（如果出現）`aclocal.m4'要舊的文件。由於在文件沒有被改變的情況下， autoheader並不改變它的輸出文件的時間標記（timestamp）。這是爲了使工作量最小化，修改時間標記是不必要的。如果你安裝了新版本的Autoconf，你可以以選項`--force'調用autoreconf而重新創建 所有的文件。
如果你在調用autoreconf時給出選項`--macrodir=dir'或者 `--localdir=dir'，它將把它們傳遞給autoconf和autoheader （相對路徑將被正確地調整）。
在同一個目錄樹中，autoreconf不支持兩個目錄作爲同一個大包的一部分（共享`aclocal.m4'和 `acconfig.h'），也不支持每個目錄都是獨立包（每個目錄都有它們自己的`aclocal.m4'和 `acconfig.h'）。如果你使用了`--localdir'，它假定所有的目錄都是同一個包的一部分。如果你沒有使用 `--localdir'，它假定每個目錄都是一個獨立的包，這條限制在將來可能被取消。
關於在configure腳本的源文件發生變化的情況下自動地重新創建它們的`Makefile'規則的細節，參見自動地重新創建。這種方法正確地處理了配置頭文件模板的時間標記，但並不傳遞`--macrodir=dir'或者`--localdir=dir'。
autoreconf接受如下選項：
--help
-h
打印命令行選項的概述並且退出。
--force
-f
即使在`configure'腳本和配置頭文件比它們的輸入文件（`configure.in'，如果出現了`aclocal.m4'，也包括它）更新的時候，也要重新創建它們。
--localdir=dir
-l dir
讓autoconf和autoheader在目錄dir中，而不是在每個包含`configure.in' 的目錄中尋找包文件`aclocal.m4'和（僅指autoheader）`acconfig.h' （但不包括`file.top'和`file.bot'）。
--macrodir=dir
-m dir
在目錄dir中，而不是缺省安裝目錄中尋找Autoconf宏文件。你還可以把環境變量 AC_MACRODIR設置成一個目錄；本選項將覆蓋該環境變量。
--verbose
打印autoreconf運行autoconf（如果適當，還有autoheader）的每個目錄的目錄名。
--version
打印Autoconf的版本號並且退出。
初始化和輸出文件
Autoconf生成的configure腳本需要一些關於如何進行初始化，諸如如何尋找包的源文件，的信息；以及如何生成輸出文件的信息。本節敘述如何進行初始化和創建輸出文件。
尋找configure的輸入文件
所有configure腳本在作任何其他事情之前都必須調用AC_INIT。此外唯一必須調用的宏是 AC_OUTPUT（參見創建輸出文件）。
宏： AC_INIT (unique-file-in-source-dir)
處理所有命令行參數並且尋找源代碼目錄。unique-file-in-source-dir是一些在包的源代碼目錄中文件； configure在目錄中檢查這些文件是否存在以確定該目錄是否包含源代碼。人們可能偶爾會用`--srcdir'給出錯誤的目錄；這是一種安全性檢查。詳情請參見運行configure腳本。
對於需要手工配置或者使用install程序的包來說，雖然在缺省源代碼位置在大部分情況下看起來是正確的，包還是可能需要通過調用AC_CONFIG_AUX_DIR來告訴 configure到那裏去尋找一些其他的shell腳本。
宏： AC_CONFIG_AUX_DIR (dir)
在目錄dir中使用`install-sh'、`config.sub'、`config.guess'和 Cygnus configure配置腳本。它們是配置中使用的輔助文件。dir既可以是絕對路徑，也可以是相對於`srcdir'的相對路徑。缺省值是在`srcdir'或者 `srcdir/..'或者`srcdir/../..'中首先找到`install-sh' 的目錄。不對其他文件進行檢查，以便使AC_PROG_INSTALL不會自動地發佈其他輔助文件。它還要檢查`install.sh'，但因爲有些make程序包含了在沒有`Makefile'的情況下從`install.sh'中創建`install'的規則，所以那個名字過時了。
創建輸出文件
每個Autoconf生成的configure腳本必須以對AC_OUTPUT的調用結尾。它是一個創建作爲配置結果的`Makefile'以及其他一些可能的文件的宏。此外唯一必須調用的宏是AC_INIT （參見尋找configure的輸入文件）。
宏： AC_OUTPUT ([file... [, extra-cmds [, init-cmds]]])
創建輸出文件。
在`configure.in'的末尾調用本宏一次。參數file...是一個以空格分隔的輸出文件的列表；它可能爲空。本宏通過從一個輸入文件（缺省情況下名爲`file.in'）中複製，並替換輸出變量的值以創建每個給出的`file'。
在`configure.in'的末尾調用本宏一次。參數file...是一個以空格分隔的輸出文件的列表；它可能爲空。本宏通過從一個輸入文件（缺省情況下名爲`file.in'）中複製，並替換輸出變量的值以創建每個給出的`file'。
關於使用輸出變量的詳情，請參見Makefile中的替換。關於創建輸出變量的詳情，請參見設定輸出變量。如果輸出文件所在的目錄不存在，本宏將創建該目錄（但不會創建目錄的父目錄）。通常，`Makefile'是按照這種方式創建的，但其他文件，例如`.gdbinit'，也可以這樣創建。
如果調用了AC_CONFIG_HEADER、AC_LINK_FILES或者AC_CONFIG_SUBDIRS，本宏也將創建出現在它們的參數中的文件。
一個典型的對AC_OUTPUT調用如下：
AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile)
你可以通過在file之後添加一個用冒號分隔的輸入文件列表以自行設定輸入文件名。例如：
AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk)
AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk)
這樣做可以使得你的文件名能夠被MS-DOS接受，或者可以把模板文件（boilerplate）添加到文件的開頭或者結尾。
如果你給出了extra-cmds，那麼這些命令將被插入到`config.status'中以便在`config.status' 完成了其他的所有處理之後運行extra-cmds。如果給出了init-cmds，它們就被插入 extra-cmds之前，並且在configure中將對它們進行shell變量、命令和反斜線替換。你可以用 init-cmds把變量從configure中傳遞到extra-cmds。如果調用了 AC_OUTPUT_COMMANDS，在其中給出的命令將緊貼在由本宏給出的命令之前運行。
宏： AC_OUTPUT_COMMANDS (extra-cmds [, init-cmds])
指定在`config.status'末尾運行的附加的shell命令，以及用於初始化來自於configure 的所有變量的shell命令。本宏可以被調用多次。下面是一個不太實際的例子：
fubar=27
AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], fubar=$fubar)
AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit])
如果你在子目錄中運行make，你應該通過使用make變量MAKE來運行它。 make的大部分版本把MAKE設置成make的程序 名以及它所需要的任何選項。（但許多版本並沒有把在命令行中設定的變量的值包括進來，因此它們沒有被自動地傳遞。）一些老版本的 make並不設定這個變量。以下的宏使你可以在這些版本上使用它。
宏： AC_PROG_MAKE_SET
如果make預定義了變量MAKE，把輸出變量SET_MAKE定義爲空。否則，把 SET_MAKE定義成`MAKE=make'。爲SET_MAKE調用AC_SUBST。
爲了使用這個宏，在每個其他的、運行MAKE的目錄中的`Makefile.in'添加一行：
@SET_MAKE@
Makefiles中的替換
發佈版本中每個包含了需要被編譯或者被安裝的文件的目錄都應該含有一個文件`Makefile.in'， configure將利用它在那個目錄中創建一個`Makefile'。爲了創建`Makefile'，configure進行一個簡單的變量替換：用configure 爲`@variable@'選取的值，在`Makefile.in'中對它們進行替換。按照這種方式被替換到輸出文件中的變量被稱爲輸出變量。在configure中，它們是普通的shell變量。爲了讓configure把特殊的變量替換到輸出文件中，必須把那個變量的名字作爲調用 AC_SUBST的參數。其他變量的任何`@variable@'都保持不變。關於使用AC_SUBST創建輸出變量的詳情，請參見設定輸出變量。
使用configure腳本的軟件應該發佈文件`Makefile.in'，而不是`Makefile'；這樣，用戶就可以在編譯它之前正確地爲本地系統進行配置了。
關於應該把哪些東西放入`Makefile'的詳情，請參見GNU編碼標準中的`Makefile慣例'。
預定義輸出變量
有些輸出變量是由Autoconf宏預定義的。一部分Autoconf宏設置一些附加的輸出變量，這些變量在對這些宏的描述中被說明。關於輸出變量的完整列表，參見輸出變量索引。下面是每個預定義變量所包含的內容。關於變量名以`dir'結尾的變量，參見GNU編碼標準中的 `爲安裝目錄而提供的變量'。
變量： bindir
用於安裝由用戶運行的可執行文件的目錄。
變量： configure_input
一個用於說明文件是由configure自動生成的，並且給出了輸入文件名的註釋。 AC_OUTPUT在它創建的每個`Makefile'文件的開頭添加一個包括了這個變量的註釋行。對於其他文件，你應該在每個輸入文件開頭處的註釋中引用這個變量。例如，一個輸入shell腳本應該以如下行開頭：
#! /bin/sh
# @configure_input@
這一行的存在也提醒了人們在編輯這個文件之後需要用configure進行處理以使用它。
變量： datadir
用於安裝只讀的與結構無關的數據的目錄。
變量： exec_prefix
與結構有關的文件的安裝前綴。
變量： includedir
用於安裝C頭文件的目錄。
變量： infodir
用於安裝Info格式文檔的目錄。
變量： libdir
用於安裝目標代碼庫的目錄。
變量： libexecdir
用於安裝由其他程序運行的可執行文件的目錄。
變量： localstatedir
用於安裝可以被修改的單機數據的目錄。
變量： mandir
用於安裝man格式的文檔的頂層目錄。
變量： oldincludedir
用於安裝由非gcc編譯器使用的C頭文件的目錄。
變量： prefix
與結構無關的文件的安裝前綴。
變量： sbindir
用於安裝由系統管理員運行的可執行文件的目錄。
變量： sharedstatedir
用於安裝可以修改的、與結構無關的數據的目錄。
變量： srcdir
包含了由`Makefile'使用的源代碼的目錄。
變量： sysconfdir
用於安裝只讀的單機數據的目錄。
變量： top_srcdir
包的頂層源代碼目錄。在目錄的頂層，它與srcdir相同。
變量： CFLAGS
爲C編譯器提供的調試和優化選項。如果在運行configure時，沒有在環境中設置它，就在你調用AC_PROG_CC的時候設置它的缺省值（如果你沒有調用AC_PROG_CC，它就爲空）。 configure在編譯程序以測試C的特徵時，使用本變量。
變量： CPPFLAGS
爲C預處理器和編譯器提供頭文件搜索目錄選項（`-Idir'）以及其他各種選項。如果在運行 configure時，在環境中沒有設置本變量，缺省值就是空。configure在編譯或者預處理程序以測試C的特徵時，使用本變量。
變量： CXXFLAGS
爲C++編譯器提供的調試和優化選項。如果在運行configure時，沒有在環境中設置本變量，那麼就在你調用AC_PROG_CXX時設置它的缺省值（如果你沒有調用AC_PROG_CXX，它就爲空）。 configure在編譯程序以測試C++的特徵時，使用本變量。
變量： FFLAGS
爲Fortran 77編譯器提供的調試和優化選項。如果在運行configure時，在環境中沒有設置本變量，那麼它的缺省值就在你調用AC_PROG_F77時被設置（如果你沒有調用AC_PROG_F77，它就爲空）。 configure在編譯程序以測試Fortran 77的特徵時，使用本變量。
變量： DEFS
傳遞給C編譯器的`-D'選項。如果調用了AC_CONFIG_HEADER，configure就用 `-DHAVE_CONFIG_H'代替`@DEFS@'（參見配置頭文件）。在configure進行它的測試時，本變量沒有被定義，只有在創建輸出文件時候才定義。關於如何檢查從前的測試結果，請參見設定輸出變量。
變量： LDFLAGS
爲連接器提供的Stripping（`-s'）選項和其他各種選項。如果在運行configure時，在環境中沒有設置本變量，它的缺省值就是空。 configure在連接程序以測試C的特徵時使用本變量。
變量： LIBS
傳遞給連接器的`-l'和`-L'選項。
創建目錄
你可以支持從一個軟件包的一份源代碼拷貝中爲多種結構同時進行編譯的功能 。爲每種結構生成的目標文件都在它們自己的目錄中儲存。
爲了支持這個功能，make用變量VPATH來尋找儲存在源代碼目錄中的文件。 GNU make和其他大部分近來的make程序都可以這樣做。老版本的make 程序不支持VPATH；在使用它們的時候，源代碼必須與目標代碼處於同一個目錄。
爲了支持VPATH，每個`Makefile.in'文件都應該包含下列兩行：
srcdir = @srcdir@
VPATH = @srcdir@
不要把VPATH設置成其他變量的值，比如說`VPATH = $(srcdir)'，這是因爲某些版本的make並不對VPATH的值進行變量替換。
在configure生成`Makefile'的時候，它用正確的值對srcdir進行替換。
除非在隱含規則中，不要使用make變量$<，它將被展開成到源代碼目錄的文件的路徑（通過VPATH找到的）。（諸如`.c.o'的隱含規則用於說明如何從`.c' 文件創建`.o'文件）有些版本的make在隱含規則中不設置$<；它們被展開成空值。
`Makefile'命令行總是應該通過使用前綴`$(srcdir)/'來引用源代碼文件。例如：
time.info: time.texinfo
$(MAKEINFO) $(srcdir)/time.texinfo
自動地重新創建
你可以在包的頂層目錄中的`Makefile.in'文件中添加如下的規則，以使得在你更新了配置文件之後可以自動地更新配置信息。這個例子包括了所有可選的文件，例如`aclocal.m4'和那些與配置頭文件有關的文件。從`Makefile.in'規則中忽略所有你的所不需要的文件。
因爲VPATH機制的限制，應該包含`${srcdir}/'前綴。
在重新創建不改變`config.h.in'和`config.h'的內容的情況下，就不會改變這兩個文件的時間標記，因此需要`stamp-'文件。這個特徵避免了不必要的重新編譯工作。你應該把文件`stamp-h.in' 包含在你的包的發佈中，以便make能夠把`config.h.in'看作是更新了的文件。在一些老的BSD系統中，touch或者任何可能導致空文件的命令不會更改時間標記，所以使用諸如echo 之類的命令。
${srcdir}/configure: configure.in aclocal.m4
cd ${srcdir} && autoconf
# autoheader might not change config.h.in, so touch a stamp file.
${srcdir}/config.h.in: stamp-h.in
${srcdir}/stamp-h.in: configure.in aclocal.m4 acconfig.h \
config.h.top config.h.bot
cd ${srcdir} && autoheader
echo timestamp > ${srcdir}/stamp-h.in
config.h: stamp-h
stamp-h: config.h.in config.status
./config.status
Makefile: Makefile.in config.status
./config.status
config.status: configure
./config.status --recheck
此外，你應該把`echo timestamp > stamp-h'作爲extra-cmds參數傳遞給AC_OUTPUT，以便`config.status'能夠確認`config.h'是更新了的。關於AC_OUTPUT的詳情，請參見 創建輸出文件。
關於處理與配置相關的依賴性問題的更多例子，請參見重新創建一個配置。
配置頭文件
在包測試的C預處理器符號比較多的時候，用於把`-D'傳遞給編譯器的命令行就會變得很長。這導致了兩個問題。一個是通過觀察尋找make輸出中的錯誤變得困難了。更嚴重的是，命令行可能超過某些操作系統的長度限制。作爲把`-D'選項傳遞給編譯器的替代辦法，configure 腳本可以創建一個包含了`#define'指令的C頭文件。宏AC_CONFIG_HEADER 選擇了這種輸出。它應該在AC_INIT之後立即調用。
包應該在引入其他任何頭文件之前`#include'配置頭文件，以防止出現聲明中的不一致性（例如，配置頭文件可能重定義了const）。使用`#include ' 並且把選項`-I.'（或者是`-I..'；或者是任何包含`config.h' 的目錄）傳遞給C編譯器，而不是使用`#include "config.h"'。按照這種方式，即使源代碼自行進行配置（可能是創建發佈版本），其他創建目錄也可以在沒有找到`config.h'的情況下，從源代碼目錄進行配置。
宏： AC_CONFIG_HEADER (header-to-create ...)
使得AC_OUTPUT創建出現在以空格分隔的列表header-to-create中的文件，以包含C預處理器#define語句，並在生成的文件中用`-DHAVE_CONFIG_H' ，而不是用DEFS的值，替換`@DEFS@'。常用在header-to-create 中的文件名是`config.h'。
如果header-to-create給出的文件已經存在並且它的內容和AC_OUTPUT將要生成的內容完全一致，這些文件就保持不變。這樣做就使得對配置的某些修改不會導致對依賴於頭文件的目標文件進行不必要的重新編譯。
通常輸入文件被命名爲`header-to-create.in'；然而，你可以通過在header-to-create 之後添加由冒號分隔的輸入文件列表來覆蓋原輸入文件名。例：
AC_CONFIG_HEADER(defines.h:defines.hin)
AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post)
這樣做使得你的文件名能夠被MS-DOS所接受，或者可以把模板（boilerplate）添加到文件的開頭和/或結尾。
配置頭文件模板
你的發佈版本應該包含一個如你所望的最終的頭文件那樣的模板文件，它包括註釋、以及#define 語句的缺省值。例如，假如你的`configure.in'進行了下列調用：
AC_CONFIG_HEADER(conf.h)
AC_CHECK_HEADERS(unistd.h)
那麼你就應該在`conf.h.in'中包含下列代碼。在含有`unistd.h'的系統中，configure應該把0改成1。在其他系統中，這一行將保持不變。
/* Define as 1 if you have unistd.h. */
#define HAVE_UNISTD_H 0
如果你的代碼使用#ifdef而不是#if來測試配置選項，缺省值就可能是取消對一個變量的定義而不是把它定義成一個值。在含有`unistd.h'的系統中，configure將修改讀入的第二行 `#define HAVE_UNISTD_H 1'。在其他的系統中，（在系統預定義了那個符號的情況下） configure將以註釋的方式排除這一行。
/* Define if you have unistd.h. */
#undef HAVE_UNISTD_H
用autoheader創建`config.h.in'
程序autoheader可以創建含有C的`#define'語句的模板文件以供configure使用。如果`configure.in'調用了AC_CONFIG_HEADER(file)，autoheader就創建 `file.in'；如果給出了多文件參數，就使用第一個文件。否則，autoheader就創建 `config.h.in'。
如果你爲autoheader提供一個參數，它就使用給出的文件而不是`configure.in'，並且把頭文件輸出到標準輸出中去，而不是輸出到`config.h.in'。如果你把`-'作爲參數提供給autoheader ，它就從標準輸入中，而不是從`configure.in'中讀出，並且把頭文件輸出到標準輸出中去。
autoheader掃描`configure.in'並且找出它可能要定義的C預處理器符號。它從一個名爲 `acconfig.h'的文件中複製註釋、#define和#undef語句，該文件與Autoconf一同發佈並且一同安裝。如果當前目錄中含有`acconfig.h'文件，它也會使用這個文件。如果你用AC_DEFINE 定義了任何附加的符號，你必須在創建的那個`acconfig.h'文件中包含附加的符號。對於由 AC_CHECK_HEADERS、AC_CHECK_FUNCS、AC_CHECK_SIZEOF或者 AC_CHECK_LIB定義的符號，autoheader生成註釋和#undef語句，而不是從一個文件中複製它們，這是因爲可能的符號是無限的。
autoheader創建的文件包含了大部分#define和#undef語句，以及相關的註釋。如果`./acconfig.h'包含了字符串`@TOP@'，autoheader就把在包含`@TOP@' 的行之前的所有行復制到它生成的文件的開頭。相似地，如果`./acconfig.h'包含了字符串`@BOTTOM@'， autoheader就把那一行之後的所有行復制到它生成的文件的末尾。這兩個字符串的任何一個都可以被忽略，也可以被同時忽略。
產生相同效果的另一種辦法是在當前目錄中創建文件`file.top'（通常是`config.h.top'）和/或文件`file.bot'。如果它們存在，autoheader就把它們分別複製到它的輸出的開頭和末尾。不鼓勵使用它們是因爲它們的文件名含有兩個點，並因此不能在MS-DOS中儲存；它們在目錄中多創建了兩個文件。但如果你給出選項`--localdir=dir'以使用在其他目錄中的`acconfig.h'，它們就爲你提供了一種把定製的模板（boilerplate）放入各個獨立的`config.h.in'中的方式。
autoheader接受如下選項：
--help
-h
打印對命令行選項的概述並且退出。
--localdir=dir
-l dir
在目錄dir中，而不是在當前目錄中，尋找包文件`aclocal.m4'和`acconfig.h' （但不包括`file.top'和`file.bot'）。
--macrodir=dir
-m dir
在目錄dir中尋找安裝的宏文件和`acconfig.h'。你還可以把環境變量AC_MACRODIR 設置成一個目錄；本選項將覆蓋該環境變量。
--version
打印Autoconf的版本號並且退出。
在子目錄中配置其它包
在大多數情況下，調用AC_OUTPUT足以在子目錄中生成`Makefile'。然而，控制了多於一個獨立包的configure腳本可以使用AC_CONFIG_SUBDIRS來爲每個子目錄中的其他包運行 configure腳本。
宏： AC_CONFIG_SUBDIRS (dir ...)
使得AC_OUTPUT在每個以空格分隔的列表中給出的子目錄dir中運行configure。如果沒有發現某個給出的dir，不會作爲錯誤報告，所以一個configure腳本可以配置一個大的源代碼樹中出現的任何一個部分。如果在給出的dir中包含了`configure.in'，但沒有包含 configure，就使用由AC_CONFIG_AUXDIR找到的Cygnus configure腳本。
用與本configure腳本完全相同的命令行參數調用子目錄中的configure腳本，如果需要，會有較小的修改（例如，爲緩衝文件或者源代碼目錄調整相對路徑）。本宏還把輸出變量subdirs設置成目錄列表`dir...'。`Makefile'規則可以使用該變量以確定需要進入那些子目錄。這個宏可以多次調用。
缺省的前綴
在缺省狀態下，configure把它所安裝的文件的前綴設置成`/usr/local'。 configure的用戶可以通過選項`--prefix'和`--exec-prefix'選擇一個不同的前綴。有兩種方式修改缺省的行爲：在創建configure時，和運行configure時。
有些軟件包在缺省情況下可能需要安裝到`/usr/local'以外的目錄中。爲此，使用宏AC_PREFIX_DEFAULT。
宏： AC_PREFIX_DEFAULT (prefix)
把缺省的安裝前綴設置成prefix，而不是`/usr/local'。
對於用戶來說，讓configure根據它們已經安裝的相關程序的位置來猜測安裝前綴，可能會帶來方便。如果你希望這樣做，你可以調用AC_PREFIX_PROGRAM。
宏： AC_PREFIX_PROGRAM (program)
如果用戶沒有給出安裝前綴（使用選項`--prefix'），就按照shell的方式，在PATH中尋找 program，從而猜出一個安裝前綴。如果找到了program，就把前綴設置成包含program 的目錄的父目錄；否則，就不改變在`Makefile.in'中給定的前綴。例如，如果program是 gcc，並且PATH包括了`/usr/local/gnu/bin/gcc'，就把前綴設置爲 `/usr/local/gnu'。
configure中的版本號
以下的宏爲configure腳本管理版本號。使用它們是可選的。
宏： AC_PREREQ (version)
確保使用的是足夠新的Autoconf版本。如果用於創建configure的Autoconf的版本比version 要早，就在標準錯誤輸出打印一條錯誤消息並不會創建configure。例如：
AC_PREREQ(1.8)
如果你的`configure.in'依賴於在不同Autoconf版本中改變了的、不明顯的行爲，本宏就是有用的。如果它僅僅是需要近來增加的宏，那麼AC_PREREQ就不太有用，這是因爲程序autoconf已經告訴了用戶那些宏沒有被找到。如果`configure.in'是由一個在提供AC_PREREQ之前的更舊的 Autoconf版本處理的，也會發生同樣的事。
宏： AC_REVISION (revision-info)
把刪除了任何美元符或者雙引號的修訂標記（revision stamp）複製到configure腳本中。本宏使得你的從`configure.in'傳遞到configure的修訂標記不會在你提交（check in） configure的時候被RCS或者CVS修改。你可以容易地決定一個特定的configure 對應與`configure.in'的哪個修訂版。
把本宏放在AC_INIT之前是個好主意，它可以使修訂號接近`configure.in'和configure 的開頭。爲了支持你這樣做，AC_REVISION就像configure通常作的那樣，以 `#! /bin/sh'開始它的輸出。
例如，在`configure.in'中這一行爲：
AC_REVISION($Revision: 1.30 $)dnl
在configure中產生了：
#! /bin/sh
# From configure.in Revision: 1.30
如果調用了AC_CONFIG_HEADER、AC_LINK_FILES或者AC_CONFIG_SUBDIRS，本宏也將創建出現在它們的參數中的文件。
一個典型的對AC_OUTPUT調用如下：
AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile)
你可以通過在file之後添加一個用冒號分隔的輸入文件列表以自行設定輸入文件名。例如：
AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk)
AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk)
這樣做可以使得你的文件名能夠被MS-DOS接受，或者可以把模板文件（boilerplate）添加到文件的開頭或者結尾。
如果你給出了extra-cmds，那麼這些命令將被插入到`config.status'中以便在`config.status' 完成了其他的所有處理之後運行extra-cmds。如果給出了init-cmds，它們就被插入 extra-cmds之前，並且在configure中將對它們進行shell變量、命令和反斜線替換。你可以用 init-cmds把變量從configure中傳遞到extra-cmds。如果調用了 AC_OUTPUT_COMMANDS，在其中給出的命令將緊貼在由本宏給出的命令之前運行。
宏： AC_OUTPUT_COMMANDS (extra-cmds [, init-cmds])
指定在`config.status'末尾運行的附加的shell命令，以及用於初始化來自於configure 的所有變量的shell命令。本宏可以被調用多次。下面是一個不太實際的例子：
fubar=27
AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], fubar=$fubar)
AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit])
宏： AC_PROG_MAKE_SET
如果make預定義了變量MAKE，把輸出變量SET_MAKE定義爲空。否則，把 SET_MAKE定義成`MAKE=make'。爲SET_MAKE調用AC_SUBST。
爲了使用這個宏，在每個其他的、運行MAKE的目錄中的`Makefile.in'添加一行：
@SET_MAKE@
Makefiles中的替換
發佈版本中每個包含了需要被編譯或者被安裝的文件的目錄都應該含有一個文件`Makefile.in'， configure將利用它在那個目錄中創建一個`Makefile'。爲了創建`Makefile'，configure進行一個簡單的變量替換：用configure 爲`@variable@'選取的值，在`Makefile.in'中對它們進行替換。按照這種方式被替換到輸出文件中的變量被稱爲輸出變量。在configure中，它們是普通的shell變量。爲了讓configure把特殊的變量替換到輸出文件中，必須把那個變量的名字作爲調用 AC_SUBST的參數。其他變量的任何`@variable@'都保持不變。關於使用AC_SUBST創建輸出變量的詳情，請參見設定輸出變量。
使用configure腳本的軟件應該發佈文件`Makefile.in'，而不是`Makefile'；這樣，用戶就可以在編譯它之前正確地爲本地系統進行配置了。
關於應該把哪些東西放入`Makefile'的詳情，請參見GNU編碼標準中的`Makefile慣例'。
預定義輸出變量
有些輸出變量是由Autoconf宏預定義的。一部分Autoconf宏設置一些附加的輸出變量，這些變量在對這些宏的描述中被說明。關於輸出變量的完整列表，參見輸出變量索引。下面是每個預定義變量所包含的內容。關於變量名以`dir'結尾的變量，參見GNU編碼標準中的 `爲安裝目錄而提供的變量'。
變量： bindir
用於安裝由用戶運行的可執行文件的目錄。
變量： configure_input
一個用於說明文件是由configure自動生成的，並且給出了輸入文件名的註釋。 AC_OUTPUT在它創建的每個`Makefile'文件的開頭添加一個包括了這個變量的註釋行。對於其他文件，你應該在每個輸入文件開頭處的註釋中引用這個變量。例如，一個輸入shell腳本應該以如下行開頭：
#! /bin/sh
# @configure_input@
這一行的存在也提醒了人們在編輯這個文件之後需要用configure進行處理以使用它。
變量： datadir
用於安裝只讀的與結構無關的數據的目錄。
變量： exec_prefix
與結構有關的文件的安裝前綴。
變量： includedir
用於安裝C頭文件的目錄。
變量： infodir
用於安裝Info格式文檔的目錄。
變量： libdir
用於安裝目標代碼庫的目錄。
變量： libexecdir
用於安裝由其他程序運行的可執行文件的目錄。
變量： localstatedir
用於安裝可以被修改的單機數據的目錄。
變量： mandir
用於安裝man格式的文檔的頂層目錄。
變量： oldincludedir
用於安裝由非gcc編譯器使用的C頭文件的目錄。
變量： prefix
與結構無關的文件的安裝前綴。
變量： sbindir
用於安裝由系統管理員運行的可執行文件的目錄。
變量： sharedstatedir
用於安裝可以修改的、與結構無關的數據的目錄。
變量： srcdir
包含了由`Makefile'使用的源代碼的目錄。
變量： sysconfdir
用於安裝只讀的單機數據的目錄。
變量： top_srcdir
包的頂層源代碼目錄。在目錄的頂層，它與srcdir相同。
變量： CFLAGS
爲C編譯器提供的調試和優化選項。如果在運行configure時，沒有在環境中設置它，就在你調用AC_PROG_CC的時候設置它的缺省值（如果你沒有調用AC_PROG_CC，它就爲空）。 configure在編譯程序以測試C的特徵時，使用本變量。
變量： CPPFLAGS
爲C預處理器和編譯器提供頭文件搜索目錄選項（`-Idir'）以及其他各種選項。如果在運行 configure時，在環境中沒有設置本變量，缺省值就是空。configure在編譯或者預處理程序以測試C的特徵時，使用本變量。
變量： CXXFLAGS
爲C++編譯器提供的調試和優化選項。如果在運行configure時，沒有在環境中設置本變量，那麼就在你調用AC_PROG_CXX時設置它的缺省值（如果你沒有調用AC_PROG_CXX，它就爲空）。 configure在編譯程序以測試C++的特徵時，使用本變量。
變量： FFLAGS
爲Fortran 77編譯器提供的調試和優化選項。如果在運行configure時，在環境中沒有設置本變量，那麼它的缺省值就在你調用AC_PROG_F77時被設置（如果你沒有調用AC_PROG_F77，它就爲空）。 configure在編譯程序以測試Fortran 77的特徵時，使用本變量。
變量： DEFS
傳遞給C編譯器的`-D'選項。如果調用了AC_CONFIG_HEADER，configure就用 `-DHAVE_CONFIG_H'代替`@DEFS@'（參見配置頭文件）。在configure進行它的測試時，本變量沒有被定義，只有在創建輸出文件時候才定義。關於如何檢查從前的測試結果，請參見設定輸出變量。
變量： LDFLAGS
爲連接器提供的Stripping（`-s'）選項和其他各種選項。如果在運行configure時，在環境中沒有設置本變量，它的缺省值就是空。 configure在連接程序以測試C的特徵時使用本變量。
變量： LIBS
傳遞給連接器的`-l'和`-L'選項。
創建目錄
爲了支持這個功能，make用變量VPATH來尋找儲存在源代碼目錄中的文件。 GNU make和其他大部分近來的make程序都可以這樣做。老版本的make 程序不支持VPATH；在使用它們的時候，源代碼必須與目標代碼處於同一個目錄。
爲了支持VPATH，每個`Makefile.in'文件都應該包含下列兩行：
srcdir = @srcdir@
VPATH = @srcdir@
不要把VPATH設置成其他變量的值，比如說`VPATH = $(srcdir)'，這是因爲某些版本的make並不對VPATH的值進行變量替換。
在configure生成`Makefile'的時候，它用正確的值對srcdir進行替換。
除非在隱含規則中，不要使用make變量$<，它將被展開成到源代碼目錄的文件的路徑（通過VPATH找到的）。（諸如`.c.o'的隱含規則用於說明如何從`.c' 文件創建`.o'文件）有些版本的make在隱含規則中不設置$<；它們被展開成空值。
`Makefile'命令行總是應該通過使用前綴`$(srcdir)/'來引用源代碼文件。例如：
time.info: time.texinfo
$(MAKEINFO) $(srcdir)/time.texinfo
自動地重新創建
你可以在包的頂層目錄中的`Makefile.in'文件中添加如下的規則，以使得在你更新了配置文件之後可以自動地更新配置信息。這個例子包括了所有可選的文件，例如`aclocal.m4'和那些與配置頭文件有關的文件。從`Makefile.in'規則中忽略所有你的所不需要的文件。
因爲VPATH機制的限制，應該包含`${srcdir}/'前綴。
在重新創建不改變`config.h.in'和`config.h'的內容的情況下，就不會改變這兩個文件的時間標記，因此需要`stamp-'文件。這個特徵避免了不必要的重新編譯工作。你應該把文件`stamp-h.in' 包含在你的包的發佈中，以便make能夠把`config.h.in'看作是更新了的文件。在一些老的BSD系統中，touch或者任何可能導致空文件的命令不會更改時間標記，所以使用諸如echo 之類的命令。
${srcdir}/configure: configure.in aclocal.m4
cd ${srcdir} && autoconf
# autoheader might not change config.h.in, so touch a stamp file.
${srcdir}/config.h.in: stamp-h.in
${srcdir}/stamp-h.in: configure.in aclocal.m4 acconfig.h \
config.h.top config.h.bot
cd ${srcdir} && autoheader
echo timestamp > ${srcdir}/stamp-h.in
config.h: stamp-h
stamp-h: config.h.in config.status
./config.status
Makefile: Makefile.in config.status
./config.status
config.status: configure
./config.status --recheck
此外，你應該把`echo timestamp > stamp-h'作爲extra-cmds參數傳遞給AC_OUTPUT，以便`config.status'能夠確認`config.h'是更新了的。關於AC_OUTPUT的詳情，請參見 創建輸出文件。
關於處理與配置相關的依賴性問題的更多例子，請參見重新創建一個配置。
配置頭文件
在包測試的C預處理器符號比較多的時候，用於把`-D'傳遞給編譯器的命令行就會變得很長。這導致了兩個問題。一個是通過觀察尋找make輸出中的錯誤變得困難了。更嚴重的是，命令行可能超過某些操作系統的長度限制。作爲把`-D'選項傳遞給編譯器的替代辦法，configure 腳本可以創建一個包含了`#define'指令的C頭文件。宏AC_CONFIG_HEADER 選擇了這種輸出。它應該在AC_INIT之後立即調用。
包應該在引入其他任何頭文件之前`#include'配置頭文件，以防止出現聲明中的不一致性（例如，配置頭文件可能重定義了const）。使用`#include ' 並且把選項`-I.'（或者是`-I..'；或者是任何包含`config.h' 的目錄）傳遞給C編譯器，而不是使用`#include "config.h"'。按照這種方式，即使源代碼自行進行配置（可能是創建發佈版本），其他創建目錄也可以在沒有找到`config.h'的情況下，從源代碼目錄進行配置。
宏： AC_CONFIG_HEADER (header-to-create ...)
使得AC_OUTPUT創建出現在以空格分隔的列表header-to-create中的文件，以包含C預處理器#define語句，並在生成的文件中用`-DHAVE_CONFIG_H' ，而不是用DEFS的值，替換`@DEFS@'。常用在header-to-create 中的文件名是`config.h'。
如果header-to-create給出的文件已經存在並且它的內容和AC_OUTPUT將要生成的內容完全一致，這些文件就保持不變。這樣做就使得對配置的某些修改不會導致對依賴於頭文件的目標文件進行不必要的重新編譯。
通常輸入文件被命名爲`header-to-create.in'；然而，你可以通過在header-to-create 之後添加由冒號分隔的輸入文件列表來覆蓋原輸入文件名。例：
AC_CONFIG_HEADER(defines.h:defines.hin)
AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post)
這樣做使得你的文件名能夠被MS-DOS所接受，或者可以把模板（boilerplate）添加到文件的開頭和/或結尾。
配置頭文件模板
你的發佈版本應該包含一個如你所望的最終的頭文件那樣的模板文件，它包括註釋、以及#define 語句的缺省值。例如，假如你的`configure.in'進行了下列調用：
AC_CONFIG_HEADER(conf.h)
AC_CHECK_HEADERS(unistd.h)
那麼你就應該在`conf.h.in'中包含下列代碼。在含有`unistd.h'的系統中，configure應該把0改成1。在其他系統中，這一行將保持不變。
/* Define as 1 if you have unistd.h. */
#define HAVE_UNISTD_H 0
如果你的代碼使用#ifdef而不是#if來測試配置選項，缺省值就可能是取消對一個變量的定義而不是把它定義成一個值。在含有`unistd.h'的系統中，configure將修改讀入的第二行 `#define HAVE_UNISTD_H 1'。在其他的系統中，（在系統預定義了那個符號的情況下） configure將以註釋的方式排除這一行。
/* Define if you have unistd.h. */
#undef HAVE_UNISTD_H
用autoheader創建`config.h.in'
程序autoheader可以創建含有C的`#define'語句的模板文件以供configure使用。如果`configure.in'調用了AC_CONFIG_HEADER(file)，autoheader就創建 `file.in'；如果給出了多文件參數，就使用第一個文件。否則，autoheader就創建 `config.h.in'。
如果你爲autoheader提供一個參數，它就使用給出的文件而不是`configure.in'，並且把頭文件輸出到標準輸出中去，而不是輸出到`config.h.in'。如果你把`-'作爲參數提供給autoheader ，它就從標準輸入中，而不是從`configure.in'中讀出，並且把頭文件輸出到標準輸出中去。
autoheader掃描`configure.in'並且找出它可能要定義的C預處理器符號。它從一個名爲 `acconfig.h'的文件中複製註釋、#define和#undef語句，該文件與Autoconf一同發佈並且一同安裝。如果當前目錄中含有`acconfig.h'文件，它也會使用這個文件。如果你用AC_DEFINE 定義了任何附加的符號，你必須在創建的那個`acconfig.h'文件中包含附加的符號。對於由 AC_CHECK_HEADERS、AC_CHECK_FUNCS、AC_CHECK_SIZEOF或者 AC_CHECK_LIB定義的符號，autoheader生成註釋和#undef語句，而不是從一個文件中複製它們，這是因爲可能的符號是無限的。
autoheader創建的文件包含了大部分#define和#undef語句，以及相關的註釋。如果`./acconfig.h'包含了字符串`@TOP@'，autoheader就把在包含`@TOP@' 的行之前的所有行復制到它生成的文件的開頭。相似地，如果`./acconfig.h'包含了字符串`@BOTTOM@'， autoheader就把那一行之後的所有行復制到它生成的文件的末尾。這兩個字符串的任何一個都可以被忽略，也可以被同時忽略。
產生相同效果的另一種辦法是在當前目錄中創建文件`file.top'（通常是`config.h.top'）和/或文件`file.bot'。如果它們存在，autoheader就把它們分別複製到它的輸出的開頭和末尾。不鼓勵使用它們是因爲它們的文件名含有兩個點，並因此不能在MS-DOS中儲存；它們在目錄中多創建了兩個文件。但如果你給出選項`--localdir=dir'以使用在其他目錄中的`acconfig.h'，它們就爲你提供了一種把定製的模板（boilerplate）放入各個獨立的`config.h.in'中的方式。
autoheader接受如下選項：
--help
-h
打印對命令行選項的概述並且退出。
--localdir=dir
-l dir
在目錄dir中，而不是在當前目錄中，尋找包文件`aclocal.m4'和`acconfig.h' （但不包括`file.top'和`file.bot'）。
--macrodir=dir
-m dir
在目錄dir中尋找安裝的宏文件和`acconfig.h'。你還可以把環境變量AC_MACRODIR 設置成一個目錄；本選項將覆蓋該環境變量。
--version
打印Autoconf的版本號並且退出。
在子目錄中配置其它包
在大多數情況下，調用AC_OUTPUT足以在子目錄中生成`Makefile'。然而，控制了多於一個獨立包的configure腳本可以使用AC_CONFIG_SUBDIRS來爲每個子目錄中的其他包運行 configure腳本。
宏： AC_CONFIG_SUBDIRS (dir ...)
使得AC_OUTPUT在每個以空格分隔的列表中給出的子目錄dir中運行configure。如果沒有發現某個給出的dir，不會作爲錯誤報告，所以一個configure腳本可以配置一個大的源代碼樹中出現的任何一個部分。如果在給出的dir中包含了`configure.in'，但沒有包含 configure，就使用由AC_CONFIG_AUXDIR找到的Cygnus configure腳本。
用與本configure腳本完全相同的命令行參數調用子目錄中的configure腳本，如果需要，會有較小的修改（例如，爲緩衝文件或者源代碼目錄調整相對路徑）。本宏還把輸出變量subdirs設置成目錄列表`dir...'。`Makefile'規則可以使用該變量以確定需要進入那些子目錄。這個宏可以多次調用。
缺省的前綴
在缺省狀態下，configure把它所安裝的文件的前綴設置成`/usr/local'。 configure的用戶可以通過選項`--prefix'和`--exec-prefix'選擇一個不同的前綴。有兩種方式修改缺省的行爲：在創建configure時，和運行configure時。
有些軟件包在缺省情況下可能需要安裝到`/usr/local'以外的目錄中。爲此，使用宏AC_PREFIX_DEFAULT。
宏： AC_PREFIX_DEFAULT (prefix)
把缺省的安裝前綴設置成prefix，而不是`/usr/local'。
對於用戶來說，讓configure根據它們已經安裝的相關程序的位置來猜測安裝前綴，可能會帶來方便。如果你希望這樣做，你可以調用AC_PREFIX_PROGRAM。
宏： AC_PREFIX_PROGRAM (program)
如果用戶沒有給出安裝前綴（使用選項`--prefix'），就按照shell的方式，在PATH中尋找 program，從而猜出一個安裝前綴。如果找到了program，就把前綴設置成包含program 的目錄的父目錄；否則，就不改變在`Makefile.in'中給定的前綴。例如，如果program是 gcc，並且PATH包括了`/usr/local/gnu/bin/gcc'，就把前綴設置爲 `/usr/local/gnu'。
configure中的版本號
以下的宏爲configure腳本管理版本號。使用它們是可選的。
宏： AC_PREREQ (version)
確保使用的是足夠新的Autoconf版本。如果用於創建configure的Autoconf的版本比version 要早，就在標準錯誤輸出打印一條錯誤消息並不會創建configure。例如：
AC_PREREQ(1.8)
如果你的`configure.in'依賴於在不同Autoconf版本中改變了的、不明顯的行爲，本宏就是有用的。如果它僅僅是需要近來增加的宏，那麼AC_PREREQ就不太有用，這是因爲程序autoconf已經告訴了用戶那些宏沒有被找到。如果`configure.in'是由一個在提供AC_PREREQ之前的更舊的 Autoconf版本處理的，也會發生同樣的事。
宏： AC_REVISION (revision-info)
把刪除了任何美元符或者雙引號的修訂標記（revision stamp）複製到configure腳本中。本宏使得你的從`configure.in'傳遞到configure的修訂標記不會在你提交（check in） configure的時候被RCS或者CVS修改。你可以容易地決定一個特定的configure 對應與`configure.in'的哪個修訂版。
把本宏放在AC_INIT之前是個好主意，它可以使修訂號接近`configure.in'和configure 的開頭。爲了支持你這樣做，AC_REVISION就像configure通常作的那樣，以 `#! /bin/sh'開始它的輸出。
例如，在`configure.in'中這一行爲：
AC_REVISION($Revision: 1.30 $)dnl
在configure中產生了：
#! /bin/sh
# From configure.in Revision: 1.30
現有的測試
這些宏測試了包可能需要或者需要使用的特定的系統特徵。如果你要測試這些宏所不能測試的特徵，可能你可以用適當的參數調用主測試宏來達到目的（參見編寫測試）。
這些宏打印消息以告訴用戶它們正在測試的特徵，以及它們的測試結果。它們爲未來運行的configure 儲存測試結果（參見緩存結果）。
在這些宏中，有的宏設置輸出變量。關於如何獲取它們的值，請參見Makefile中的替換。在下面出現的術語“定義name”是“把C預處理符號name定義成1”的簡稱。關於如何把這些符號的定義放入你的程序中，參見定義C預處理器符號。
對程序的選擇
這些宏檢查了特定程序的存在或者特定程序的特徵。它們被用於在幾個可以相互替代的程序間進行選擇，並且在決定選用某一個的時候作些什麼。如果沒有爲你要使用的程序定義特定的宏，並且你不需要檢查它的任何特殊的特徵，那麼你就可以選用一個通用程序檢查宏。
對特定程序的檢查
這些宏檢查特定的程序--它們是否存在，並且在某些情況下它們是否支持一些特徵。
宏： AC_DECL_YYTEXT
如果yytext的類型是`char *'而不是`char []'，就定義YYTEXT_POINTER。本宏還把輸出變量LEX_OUTPUT_ROOT設置由lex生成的文件名的基文件名；通常是`lex.yy'，但有時是其他的東西。它的結果依使用lex還是使用flex而定。
宏： AC_PROG_AWK
按順序查找mawk、gawk、nawk和awk，並且把輸出變量AWK 的值設置成第一個找到的程序名。首先尋找mawk是因爲據說它是最快的實現。
宏： AC_PROG_CC
確定C的編譯器。如果在環境中沒有設定CC，就查找gcc，如果沒有找到，就使用cc。把輸出變量CC設置爲找到的編譯器的名字。
如果要使用GNU C編譯器，把shell變量GCC設置爲`yes'，否則就設置成空。如果還沒有設置輸出變量 CFLAGS，就爲GNU C編譯器把CFLAGS設置成`-g -O2'（在GCC不接受`-g' 的系統中就設置成`-O2'），爲其他編譯器把CFLAGS設置成`-g'。
如果被使用的C編譯器並不生成可以在configure運行的系統上運行的可執行文件，就把shell變量 cross_compiling設置成`yes'，否則設置成`no'。換句話說，它檢查創建系統類型是否與主機系統類型不同（目標系統與本測試無關）。關於對交叉編譯的支持，參見手工配置。
宏： AC_PROG_CC_C_O
對於不能同時接受`-c'和`-o'選項的C編譯器，定義NO_MINUS_C_MINUS_O。
宏： AC_PROG_CPP
把輸出變量CPP設置成運行C預處理器的命令。如果`$CC -E'不能工作，就使用`/lib/cpp'。只有對以`.c'爲擴展名的文件運行CPP纔是可以移植的（portable）。
如果當前語言是C（參見對語言的選擇），許多特定的測試宏通過調用AC_TRY_CPP、 AC_CHECK_HEADER、AC_EGREP_HEADER或者AC_EGREP_CPP，間接地使用了CPP的值。
宏： AC_PROG_CXX
確定C++編譯器。檢查環境變量CXX或者CCC（按照這個順序）是否被設置了；如果設置了，就把輸出變量 CXX設置成它的值。否則就搜索類似名稱（c++、g++、gcc、CC、 cxx和cc++）的C++編譯器。如果上述測試都失敗了，最後的辦法就是把CXX設置成 gcc。
如果使用GNU C++編譯器，就把shell變量GXX設置成`yes'，否則就設置成空。如果還沒有設置輸出變量CXXFLAGS，就爲GNU C++編譯器把CXXFLAGS設置成`-g -O2' （在G++不接受`-g'的系統上設置成`-O2'），或者爲其他編譯器把CXXFLAGS設置成 `-g'。 .
如果使用的C++編譯器並不生成在configure運行的系統上運行的可執行文件，就把shell變量cross_compiling 設置成`yes'，否則就設置成`no'。換句話說，它檢查創建系統類型是否與主機系統類型不同（目標系統類型與本測試無關）。關於對交叉編譯的支持，參見手工配置。
宏： AC_PROG_CXXCPP
把輸出變量CXXCPP設置成運行C++預處理器的命令。如果`$CXX -E'不能工作，使用`/lib/cpp'。只有對以`.c'、`.C'或者`.cc'爲擴展名的文件運行CPP纔是可以移植的（portable）。
如果當前語言是C++（參見對語言的選擇），許多特定的測試宏通過調用 AC_TRY_CPP、AC_CHECK_HEADER、AC_EGREP_HEADER或者AC_EGREP_CPP，間接地使用了CXXCPP的值。
宏： AC_PROG_F77
確定Fortran 77編譯器。如果在環境中沒有設置F77，就按順序檢查g77、f77和 f2c。把輸出變量F77設置成找到的編譯器的名字。
如果使用g77（GNU Fortran 77編譯器），那麼AC_PROG_F77將把shell變量G77設置成 `yes'，否則就設置成空。如果在環境中沒有設置輸出變量FFLAGS，那麼就爲g77 把FFLAGS設置成`-g -02'（或者在g77不支持`-g'的時候設置成 `-O2'）。否則，就爲所有其它的Fortran 77編譯器把FFLAGS設置成`-g'。
宏： AC_PROG_F77_C_O
測試Fortran 77編譯器是否能夠同時接受選項`-c'和`-o'，並且如果不能同時接受的話，就定義F77_NO_MINUS_C_MINUS_O。
宏： AC_PROG_GCC_TRADITIONAL
如果在沒有給出`-traditional'的情況下，用GNU C和ioctl不能正確地工作，就把 `-traditional'添加到輸出變量CC中。這通常發生在舊系統上沒有安裝修正了的頭文件的時候。因爲新版本的GNU C編譯器在安裝的時候自動地修正了頭文件，它就不是一個普遍的問題了。
宏： AC_PROG_INSTALL
如果在當前PATH中找到了一個與BSD兼容的install程序，就把輸出變量INSTALL設置成到該程序的路徑。否則，就把INSTALL設置成`dir/install-sh -c'，檢查由 AC_CONFIG_AUX_DIR指明的目錄（或者它的缺省目錄）以確定dir（參見 創建輸出文件）。本宏還把變量INSTALL_PROGRAM和INSTALL_SCRIPT 設置成`${INSTALL}'，並且把INSTALL_DATA設置成`${INSTALL} -m 644'。
本宏忽略各種已經確認的不能工作的install程序。爲了提高速度，它更希望找到一個C程序而不是shell腳本。除了`install-sh'，它還能夠使用`install.sh'，但因爲有些make含有一條在沒有 `Makefile'的情況下，從`install.sh'創建`install'的規則，所以這個名字過時了。
你可能使用的`install-sh'的一個副本來自於Autoconf。如果你使用AC_PROG_INSTALL，你必須在你的發佈版本中包含`install-sh'或者`install.sh'，否則即使你所在的系統含有一個好的install 程序，configure也將輸出一條找不到它們的錯誤消息。
如果你因爲你自己的安裝程序提供了一些在標準install程序中沒有的特徵，而需要使用你自己的安裝程序，就沒有必要使用AC_PROG_INSTALL；直接把你的程序的路徑名放入你的`Makefile.in'文件即可。
宏： AC_PROG_LEX
如果找到了flex，就把輸出變量LEX設置成`flex'，並且在flex庫在標準位置的時候，把LEXLIB設置成`-lfl'。否則，就把LEX設置成`lex'並且把 LEXLIB設置成`-ll'。
宏： AC_PROG_LN_S
如果`ln -s'能夠在當前文件系統中工作（操作系統和文件系統支持符號連接），就把輸出變量 LN_S設置成`ln -s'，否則就把它設置成`ln'。
如果連接出現在其他目錄而不是在當前目錄中，它的含義依賴於是使用了`ln'，還是使用了`ln -s'。爲了用`$(LN_S)'安全地創建連接，既可以找到正在使用的形式並且調整參數，也可以總是在創建連接的目錄中調用ln。
換句話說，它不能像下面那樣工作：
$(LN_S) foo /x/bar
而是要：
(cd /x && $(LN_S) foo bar)
宏： AC_PROG_RANLIB
如果找到了ranlib，就把輸出變量RANLIB設置成`ranlib'，否則就設置成 `:'（什麼也不作）。
宏： AC_PROG_YACC
如果找到了bison，就把輸出變量YACC設置成`bison -y'。否則，如果找到了byacc。就把YACC設置成`byacc'。否則，就把YACC設置成`yacc'。
對普通程序和文件的檢查
這些宏用於尋找沒有包含在特定程序測試宏中的程序。如果你除了需要確定程序是否存在，還需要檢測程序的行爲，你就不得不爲它編寫你自己的測試了（參見編寫測試）。在缺省情況下，這些宏使用環境變量PATH。如果你需要檢查可能不會出現在PATH中的程序，你可能要按照下面的方式給出修改了的路徑：
AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd,
$PATH:/usr/libexec:/usr/sbin:/usr/etc:etc)
宏： AC_CHECK_FILE (file [, action-if-found [, action-if-not-found]])
檢查文件file是否出現在本地系統中。如果找到了，就執行action-if-found。否則，就在給出了 action-if-not-found的時候執行action-if-not-found。
宏： AC_CHECK_FILES (files[, action-if-found [, action-if-not-found]])
爲每個在files中給出的文件運行AC_CHECK_FILE。並且爲每個找到的文件定義 `HAVEfile'，定義成1。
宏： AC_CHECK_PROG (variable, prog-to-check-for, value-if-found [, value-if-not-found [, path, [ reject ]]])
檢查程序prog-to-check-for是否存在於PATH之中。如果找到了，就把變量 variable設置成value-if-found，否則就在給出了value-if-not-found的時候把variable設置成它。即使首先在搜索路徑中找到reject（一個絕對文件名），本宏也會忽略它；在那種情況下，用找到的prog-to-check-for，不同於reject的絕對文件名來設置variable。如果variable已經被設置了，就什麼也不作。爲variable調用AC_SUBST。
宏： AC_CHECK_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])
在PATH中尋找每個出現在以空格分隔的列表progs-to-check-for中的程序。如果找到了，就把variable設置成那個程序的名字。否則，繼續尋找列表中的下一個程序。如果列表中的任何一個程序都沒有被找到，就把variable設置成value-if-not-found；如果沒有給出value-if-not-found，variable的值就不會被改變。爲variable調用 AC_SUBST。
宏： AC_CHECK_TOOL (variable, prog-to-check-for [, value-if-not-found [, path]])
除了把AC_CANONICAL_HOST確定的主機類型和破折號作爲前綴之外，類似於AC_CHECK_PROG，尋找prog-to-check-for（參見獲取規範的系統類型）。例如，如果用戶運行`configure --host=i386-gnu'，那麼下列調用：
AC_CHECK_TOOL(RANLIB, ranlib, :)
當`i386-gnu-ranlib'在PATH中存在的時候，就把RANLIB設置成`i386-gnu-ranlib'，或者當`ranlib'在PATH中存在的時候，就把RANLIB設置成`ranlib'，或者在上述兩個程序都不存在的時候，把RANLIB設置成`:'。
宏： AC_PATH_PROG (variable, prog-to-check-for [, value-if-not-found [, path]])
類似於AC_CHECK_PROG，但在找到prog-to-check-for的時候，把variable設置成prog-to-check-for的完整路徑。
宏： AC_PATH_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])
類似於AC_CHECK_PROGS，但在找到任何一個progs-to-check-for的時候，把variable 設置成找到的程序的完整路徑。
庫文件
下列的宏檢查某些C、C++或者Fortran 77庫文件是否存在。
宏： AC_CHECK_LIB (library, function [, action-if-found [, action-if-not-found [, other-libraries]]])
依賴於當前的語言（參見對語言的選擇），試圖通過檢查一個測試程序是否可以和庫library進行連接以獲取C、C++或者Fortran 77函數function，從而確認函數function 是可以使用的。library是庫的基本名字；例如，爲了檢查`-lmp'，就把`mp'作爲參數library。
action-if-found是一個在與庫成功地進行了連接的時候運行的shell命令列表； action-if-not-found是一個在與庫的連接失敗的時候運行的shell命令列表。如果沒有給出action-if-found，缺省的動作就是把`-llibrary'添加到 LIBS中，並且定義`HAVE_LIBlibrary'（全部使用大寫字母）。
如果與library的連接導致了未定義符號錯誤（unresolved symbols），而這些錯誤可以通過與其他庫的連接來解決，就把這些庫用空格分隔，並作爲other-libraries參數給出：`-lXt -lX11'。否則，本宏對library是否存在的檢測將會失敗，這是因爲對測試程序的連接將總是因爲含有未定義符號錯誤而失敗。
宏： AC_HAVE_LIBRARY (library, [, action-if-found [, action-if-not-found [, other-libraries]]])
本宏等價於function參數爲main的，對AC_CHECK_LIB的調用。此外，library可以寫作`foo'、`-lfoo'或者`libfoo.a'。對於以上任一種形式，編譯器都使用`-lfoo'。但是，library不能是一個shell變量；它必須是一個文字名（literal name）。本宏是一個過時的宏。
宏： AC_SEARCH_LIBS (function, search-libs [, action-if-found [, action-if-not-found [, other-libraries]]])
如果function還不可用，就尋找一個定義了function的庫。這等同於首先不帶庫調用 AC_TRY_LINK_FUNC，而後爲每個在search-libs中列舉的庫調用AC_TRY_LINK_FUNC。
如果找到了函數，就運行action-if-found。否則運行action-if-not-found。
如果與庫library的連接導致了未定義符號錯誤，而這些錯誤可以通過與附加的庫進行連接來解決，就把這些庫用空格分隔，並作爲other-libraries參數給出：`-lXt -lX11'。否則，本宏對function 是否存在的檢測將總是失敗，這是因爲對測試程序的連接將總是因爲含有未定義符號錯誤而失敗。
宏： AC_SEARCH_LIBS (function, search-libs[, action-if-found [, action-if-not-found]])
本宏等價於爲每個在search-libs中列舉的庫調用一次AC_TRY_LINK_FUNC。爲找到的第一個含有 function的庫，把`-llibrary'添加到LIBS中，並且執行 action-if-found。否則就執行action-if-not-found。
庫函數
以下的宏用於檢測特定的C庫函數。如果沒有爲你需要的函數定義特定的宏，而且你不需要檢查它的任何特殊性質，那麼你可以使用一個通用函數檢測宏。
對特定函數的檢查
這些宏用於檢測特定的C函數--它們是否存在，以及在某些情況下，當給出了特定的參數時，它們是如何響應的。
宏： AC_FUNC_ALLOCA
檢測如何獲得alloca。本宏試圖通過檢查`alloca.h'或者預定義C預處理器宏 __GNUC__和_AIX來獲得alloca的內置（builtin）版本。如果本宏找到了`alloca.h'，它就定義HAVE_ALLOCA_H。
如果上述嘗試失敗了，本宏就在標準C庫中尋找函數。如果下列任何方法成功了，本宏就定義HAVE_ALLOCA。否則，它把輸出變量ALLOCA設置成`alloca.o'並且定義C_ALLOCA （這樣程序就可以週期性地調用`alloca(0)'以進行垃圾的收集）。本變量是從LIBOBJS中分離出來的，因此在只有一部分程序使用LIBOBJS中的代碼時，多個程序就可以不必創建實際的庫而共享ALLOCA的值。
本宏並不試圖從System V R3的`libPW'中，或者從System V R4的`libucb'中獲取alloca，這是因爲這些庫包含了一些造成麻煩的不兼容的函數。有些版本甚至不含有alloca或者含有帶bug的版本。如果你仍然需要使用它們的alloca，用ar把`alloca.o'從這些庫中提取出來，而不是編譯`alloca.c'。
使用alloca的源文件應該以如下一段代碼開頭，以正確地聲明它。在某些AIX版本中，對alloca 的聲明必須在除了註釋和預處理指令之前的任何東西之前出現。#pragma指令被縮進（indented），以便讓預標準C編譯器（pre-ANSI C compiler）忽略它，而不是導致錯誤（choke on it）。
/* AIX requires this to be the first thing in the file. */
#ifndef __GNUC__
# if HAVE_ALLOCA_H
# include
# else
# ifdef _AIX
#pragma alloca
# else
# ifndef alloca /* predefined by HP cc +Olibcalls */
char *alloca ();
# endif
# endif
# endif
#endif
宏： AC_FUNC_CLOSEDIR_VOID
如果函數closedir不返回有意義的值，就定義CLOSEDIR_VOID。否則，調用者就應該把它的返回值作爲錯誤指示器來進行檢查。
宏： AC_FUNC_FNMATCH
如果可以使用fnmatch函數，並且能夠工作（不象SunOS 5.4中的fnmatch那樣），就定義HAVE_FNMATCH。
宏： AC_FUNC_GETLOADAVG
檢查如何才能獲得系統平均負載。如果系統含有getloadavg函數，本宏就定義HAVE_GETLOADAVG，並且把爲了獲得該函數而需要的庫添加到LIBS中。
否則，它就把`getloadavg.o'添加到輸出變量LIBOBJS之中，並且可能定義幾個其他的C預處理器宏和輸出變量：
如果在相應的系統中，就根據系統類型定義宏SVR4、DGUX、UMAX或者UMAX4_3。
如果它找到了`nlist.h'，就定義NLIST_STRUCT。
如果結構`struct nlist'含有成員`n_un'，就定義NLIST_NAME_UNION。
如果在編譯`getloadavg.c'時定義了LDAV_PRIVILEGED，爲了使getloadavg能夠工作，程序就必須特殊地安裝在系統中，並且本宏定義GETLOADAVG_PRIVILEGED。
本宏設置輸出變量NEED_SETGID。如果需要進行特別的安裝，它的值就是`true'，否則值就是`false'。如果NEED_SETGID爲`true'，本宏把KMEM_GROUP 設置成將擁有被安裝的程序的組（group）的名字。
宏： AC_FUNC_GETMNTENT
爲Irix 4、PTX和Unixware在庫`sun'、`seq'和`gen'中分別查找getmntent函數。那麼，如果可以使用getmntent，就定義HAVE_GETMNTENT。
宏： AC_FUNC_GETPGRP
如果getpgrp不接受參數（POSIX.1版），就定義GETPGRP_VOID。否則，它就是一個把進程ID作爲參數的BSD版本。本宏根本不檢查getpgrp是否存在；如果你需要檢查它的存在性，就首先爲 getpgrp函數調用AC_CHECK_FUNC。
宏： AC_FUNC_MEMCMP
如果不能使用memcmp函數，或者不能處理8位數據（就像SunOS 4.1.3中的那樣），就把`memcmp.o' 添加到輸出變量LIBOBJS中去。
宏： AC_FUNC_MMAP
如果函數mmap存在並且能夠正確地工作，就定義HAVE_MMAP。只檢查已經映射（already-mapped）的內存的私有固定映射（private fixed mapping）。
宏： AC_FUNC_SELECT_ARGTYPES
確定函數select的每個參數的正確類型，並且把這些類型分別定義成SELECT_TYPE_ARG1、 SELECT_TYPE_ARG234和SELECT_TYPE_ARG5。SELECT_TYPE_ARG1的缺省值是`int'，SELECT_TYPE_ARG234的缺省值是`int *'， SELECT_TYPE_ARG5的缺省值是`struct timeval *'。
宏： AC_FUNC_SETPGRP
如果setpgrp不接受參數（POSIX.1版），就定義SETPGRP_VOID。否則，該函數就是一個把兩個進程ID作爲參數的BSD版本。本宏並不檢查函數setpgrp是否存在；如果你需要檢查該函數的存在性，就首先爲setpgrp調用AC_CHECK_FUNC。
宏： AC_FUNC_SETVBUF_REVERSED
如果函數setvbuf的第二個參數是緩衝區的類型並且第三個參數是緩衝區指針，而不是其他形式，就定義SETVBUF_REVERSED。這是在System V第3版以前的情況。
宏： AC_FUNC_STRCOLL
如果函數strcoll存在並且可以正確地工作，就定義HAVE_STRCOLL。由於有些系統包含了錯誤定義的strcoll，這時就不應該使用strcoll，因此本宏要比`AC_CHECK_FUNCS(strcoll)'多作一些檢查。
宏： AC_FUNC_STRFTIME
對於SCO UNIX，在庫`intl'中查找strftime。而後，如果可以使用strftime，就定義HAVE_STRFTIME。
宏： AC_FUNC_UTIME_NULL
如果`utime(file, NULL)'把file的時間標記設置成現在，就定義 HAVE_UTIME_NULL。
宏： AC_FUNC_VFORK
如果找到了`vfork.h'，就定義HAVE_VFORK_H。如果找不到可以工作的vfork，就把vfork定義成fork。本宏檢查一些已知的vfork實現中的錯誤並且認爲如果vfork的實現含有任何一個錯誤，系統就不含有可以工作的vfork。由於子進程很少改變它們的信號句柄（signal handler），所以如果子進程的signal調用（invocation）修改了父進程的信號句柄，將不會被當作實現的錯誤。
宏： AC_FUNC_VPRINTF
如果找到了vprintf，就定義HAVE_VPRINTF。否則，如果找到了_doprnt，就定義HAVE_DOPRNT。（如果可以使用vprintf，你就可以假定也可以使用vfprintf 和vsprintf。）
宏： AC_FUNC_WAIT3
如果找到了wait3並且該函數填充它的第三個參數的內容（`struct rusage *'），就定義HAVE_WAIT3。在HP-UX中，該函數並不這樣做。
這些宏測試了包可能需要或者需要使用的特定的系統特徵。如果你要測試這些宏所不能測試的特徵，可能你可以用適當的參數調用主測試宏來達到目的（參見編寫測試）。
這些宏打印消息以告訴用戶它們正在測試的特徵，以及它們的測試結果。它們爲未來運行的configure 儲存測試結果（參見緩存結果）。
在這些宏中，有的宏設置輸出變量。關於如何獲取它們的值，請參見Makefile中的替換。在下面出現的術語“定義name”是“把C預處理符號name定義成1”的簡稱。關於如何把這些符號的定義放入你的程序中，參見定義C預處理器符號。
對程序的選擇
這些宏檢查了特定程序的存在或者特定程序的特徵。它們被用於在幾個可以相互替代的程序間進行選擇，並且在決定選用某一個的時候作些什麼。如果沒有爲你要使用的程序定義特定的宏，並且你不需要檢查它的任何特殊的特徵，那麼你就可以選用一個通用程序檢查宏。
對特定程序的檢查
這些宏檢查特定的程序--它們是否存在，並且在某些情況下它們是否支持一些特徵。
宏： AC_DECL_YYTEXT
如果yytext的類型是`char *'而不是`char []'，就定義YYTEXT_POINTER。本宏還把輸出變量LEX_OUTPUT_ROOT設置由lex生成的文件名的基文件名；通常是`lex.yy'，但有時是其他的東西。它的結果依使用lex還是使用flex而定。
宏： AC_PROG_AWK
按順序查找mawk、gawk、nawk和awk，並且把輸出變量AWK 的值設置成第一個找到的程序名。首先尋找mawk是因爲據說它是最快的實現。
宏： AC_PROG_CC
確定C的編譯器。如果在環境中沒有設定CC，就查找gcc，如果沒有找到，就使用cc。把輸出變量CC設置爲找到的編譯器的名字。
如果要使用GNU C編譯器，把shell變量GCC設置爲`yes'，否則就設置成空。如果還沒有設置輸出變量 CFLAGS，就爲GNU C編譯器把CFLAGS設置成`-g -O2'（在GCC不接受`-g' 的系統中就設置成`-O2'），爲其他編譯器把CFLAGS設置成`-g'。
如果被使用的C編譯器並不生成可以在configure運行的系統上運行的可執行文件，就把shell變量 cross_compiling設置成`yes'，否則設置成`no'。換句話說，它檢查創建系統類型是否與主機系統類型不同（目標系統與本測試無關）。關於對交叉編譯的支持，參見手工配置。
宏： AC_PROG_CC_C_O
對於不能同時接受`-c'和`-o'選項的C編譯器，定義NO_MINUS_C_MINUS_O。
宏： AC_PROG_CPP
把輸出變量CPP設置成運行C預處理器的命令。如果`$CC -E'不能工作，就使用`/lib/cpp'。只有對以`.c'爲擴展名的文件運行CPP纔是可以移植的（portable）。
如果當前語言是C（參見對語言的選擇），許多特定的測試宏通過調用AC_TRY_CPP、 AC_CHECK_HEADER、AC_EGREP_HEADER或者AC_EGREP_CPP，間接地使用了CPP的值。
宏： AC_PROG_CXX
確定C++編譯器。檢查環境變量CXX或者CCC（按照這個順序）是否被設置了；如果設置了，就把輸出變量 CXX設置成它的值。否則就搜索類似名稱（c++、g++、gcc、CC、 cxx和cc++）的C++編譯器。如果上述測試都失敗了，最後的辦法就是把CXX設置成 gcc。
如果使用GNU C++編譯器，就把shell變量GXX設置成`yes'，否則就設置成空。如果還沒有設置輸出變量CXXFLAGS，就爲GNU C++編譯器把CXXFLAGS設置成`-g -O2' （在G++不接受`-g'的系統上設置成`-O2'），或者爲其他編譯器把CXXFLAGS設置成 `-g'。 .
如果使用的C++編譯器並不生成在configure運行的系統上運行的可執行文件，就把shell變量cross_compiling 設置成`yes'，否則就設置成`no'。換句話說，它檢查創建系統類型是否與主機系統類型不同（目標系統類型與本測試無關）。關於對交叉編譯的支持，參見手工配置。
宏： AC_PROG_CXXCPP
把輸出變量CXXCPP設置成運行C++預處理器的命令。如果`$CXX -E'不能工作，使用`/lib/cpp'。只有對以`.c'、`.C'或者`.cc'爲擴展名的文件運行CPP纔是可以移植的（portable）。
如果當前語言是C++（參見對語言的選擇），許多特定的測試宏通過調用 AC_TRY_CPP、AC_CHECK_HEADER、AC_EGREP_HEADER或者AC_EGREP_CPP，間接地使用了CXXCPP的值。
宏： AC_PROG_F77
確定Fortran 77編譯器。如果在環境中沒有設置F77，就按順序檢查g77、f77和 f2c。把輸出變量F77設置成找到的編譯器的名字。
如果使用g77（GNU Fortran 77編譯器），那麼AC_PROG_F77將把shell變量G77設置成 `yes'，否則就設置成空。如果在環境中沒有設置輸出變量FFLAGS，那麼就爲g77 把FFLAGS設置成`-g -02'（或者在g77不支持`-g'的時候設置成 `-O2'）。否則，就爲所有其它的Fortran 77編譯器把FFLAGS設置成`-g'。
宏： AC_PROG_F77_C_O
測試Fortran 77編譯器是否能夠同時接受選項`-c'和`-o'，並且如果不能同時接受的話，就定義F77_NO_MINUS_C_MINUS_O。
宏： AC_PROG_GCC_TRADITIONAL
如果在沒有給出`-traditional'的情況下，用GNU C和ioctl不能正確地工作，就把 `-traditional'添加到輸出變量CC中。這通常發生在舊系統上沒有安裝修正了的頭文件的時候。因爲新版本的GNU C編譯器在安裝的時候自動地修正了頭文件，它就不是一個普遍的問題了。
宏： AC_PROG_INSTALL
如果在當前PATH中找到了一個與BSD兼容的install程序，就把輸出變量INSTALL設置成到該程序的路徑。否則，就把INSTALL設置成`dir/install-sh -c'，檢查由 AC_CONFIG_AUX_DIR指明的目錄（或者它的缺省目錄）以確定dir（參見 創建輸出文件）。本宏還把變量INSTALL_PROGRAM和INSTALL_SCRIPT 設置成`${INSTALL}'，並且把INSTALL_DATA設置成`${INSTALL} -m 644'。
本宏忽略各種已經確認的不能工作的install程序。爲了提高速度，它更希望找到一個C程序而不是shell腳本。除了`install-sh'，它還能夠使用`install.sh'，但因爲有些make含有一條在沒有 `Makefile'的情況下，從`install.sh'創建`install'的規則，所以這個名字過時了。
你可能使用的`install-sh'的一個副本來自於Autoconf。如果你使用AC_PROG_INSTALL，你必須在你的發佈版本中包含`install-sh'或者`install.sh'，否則即使你所在的系統含有一個好的install 程序，configure也將輸出一條找不到它們的錯誤消息。
如果你因爲你自己的安裝程序提供了一些在標準install程序中沒有的特徵，而需要使用你自己的安裝程序，就沒有必要使用AC_PROG_INSTALL；直接把你的程序的路徑名放入你的`Makefile.in'文件即可。
宏： AC_PROG_LEX
如果找到了flex，就把輸出變量LEX設置成`flex'，並且在flex庫在標準位置的時候，把LEXLIB設置成`-lfl'。否則，就把LEX設置成`lex'並且把 LEXLIB設置成`-ll'。
宏： AC_PROG_LN_S
如果`ln -s'能夠在當前文件系統中工作（操作系統和文件系統支持符號連接），就把輸出變量 LN_S設置成`ln -s'，否則就把它設置成`ln'。
如果連接出現在其他目錄而不是在當前目錄中，它的含義依賴於是使用了`ln'，還是使用了`ln -s'。爲了用`$(LN_S)'安全地創建連接，既可以找到正在使用的形式並且調整參數，也可以總是在創建連接的目錄中調用ln。
換句話說，它不能像下面那樣工作：
$(LN_S) foo /x/bar
而是要：
(cd /x && $(LN_S) foo bar)
宏： AC_PROG_RANLIB
如果找到了ranlib，就把輸出變量RANLIB設置成`ranlib'，否則就設置成 `:'（什麼也不作）。
宏： AC_PROG_YACC
如果找到了bison，就把輸出變量YACC設置成`bison -y'。否則，如果找到了byacc。就把YACC設置成`byacc'。否則，就把YACC設置成`yacc'。
對普通程序和文件的檢查
這些宏用於尋找沒有包含在特定程序測試宏中的程序。如果你除了需要確定程序是否存在，還需要檢測程序的行爲，你就不得不爲它編寫你自己的測試了（參見編寫測試）。在缺省情況下，這些宏使用環境變量PATH。如果你需要檢查可能不會出現在PATH中的程序，你可能要按照下面的方式給出修改了的路徑：
AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd,
$PATH:/usr/libexec:/usr/sbin:/usr/etc:etc)
宏： AC_CHECK_FILE (file [, action-if-found [, action-if-not-found]])
檢查文件file是否出現在本地系統中。如果找到了，就執行action-if-found。否則，就在給出了 action-if-not-found的時候執行action-if-not-found。
宏： AC_CHECK_FILES (files[, action-if-found [, action-if-not-found]])
爲每個在files中給出的文件運行AC_CHECK_FILE。並且爲每個找到的文件定義 `HAVEfile'，定義成1。
宏： AC_CHECK_PROG (variable, prog-to-check-for, value-if-found [, value-if-not-found [, path, [ reject ]]])
檢查程序prog-to-check-for是否存在於PATH之中。如果找到了，就把變量 variable設置成value-if-found，否則就在給出了value-if-not-found的時候把variable設置成它。即使首先在搜索路徑中找到reject（一個絕對文件名），本宏也會忽略它；在那種情況下，用找到的prog-to-check-for，不同於reject的絕對文件名來設置variable。如果variable已經被設置了，就什麼也不作。爲variable調用AC_SUBST。
宏： AC_CHECK_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])
在PATH中尋找每個出現在以空格分隔的列表progs-to-check-for中的程序。如果找到了，就把variable設置成那個程序的名字。否則，繼續尋找列表中的下一個程序。如果列表中的任何一個程序都沒有被找到，就把variable設置成value-if-not-found；如果沒有給出value-if-not-found，variable的值就不會被改變。爲variable調用 AC_SUBST。
宏： AC_CHECK_TOOL (variable, prog-to-check-for [, value-if-not-found [, path]])
除了把AC_CANONICAL_HOST確定的主機類型和破折號作爲前綴之外，類似於AC_CHECK_PROG，尋找prog-to-check-for（參見獲取規範的系統類型）。例如，如果用戶運行`configure --host=i386-gnu'，那麼下列調用：
AC_CHECK_TOOL(RANLIB, ranlib, :)
當`i386-gnu-ranlib'在PATH中存在的時候，就把RANLIB設置成`i386-gnu-ranlib'，或者當`ranlib'在PATH中存在的時候，就把RANLIB設置成`ranlib'，或者在上述兩個程序都不存在的時候，把RANLIB設置成`:'。
宏： AC_PATH_PROG (variable, prog-to-check-for [, value-if-not-found [, path]])
類似於AC_CHECK_PROG，但在找到prog-to-check-for的時候，把variable設置成prog-to-check-for的完整路徑。
宏： AC_PATH_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])
類似於AC_CHECK_PROGS，但在找到任何一個progs-to-check-for的時候，把variable 設置成找到的程序的完整路徑。
庫文件
下列的宏檢查某些C、C++或者Fortran 77庫文件是否存在。
宏： AC_CHECK_LIB (library, function [, action-if-found [, action-if-not-found [, other-libraries]]])
依賴於當前的語言（參見對語言的選擇），試圖通過檢查一個測試程序是否可以和庫library進行連接以獲取C、C++或者Fortran 77函數function，從而確認函數function 是可以使用的。library是庫的基本名字；例如，爲了檢查`-lmp'，就把`mp'作爲參數library。
action-if-found是一個在與庫成功地進行了連接的時候運行的shell命令列表； action-if-not-found是一個在與庫的連接失敗的時候運行的shell命令列表。如果沒有給出action-if-found，缺省的動作就是把`-llibrary'添加到 LIBS中，並且定義`HAVE_LIBlibrary'（全部使用大寫字母）。
如果與library的連接導致了未定義符號錯誤（unresolved symbols），而這些錯誤可以通過與其他庫的連接來解決，就把這些庫用空格分隔，並作爲other-libraries參數給出：`-lXt -lX11'。否則，本宏對library是否存在的檢測將會失敗，這是因爲對測試程序的連接將總是因爲含有未定義符號錯誤而失敗。
宏： AC_HAVE_LIBRARY (library, [, action-if-found [, action-if-not-found [, other-libraries]]])
本宏等價於function參數爲main的，對AC_CHECK_LIB的調用。此外，library可以寫作`foo'、`-lfoo'或者`libfoo.a'。對於以上任一種形式，編譯器都使用`-lfoo'。但是，library不能是一個shell變量；它必須是一個文字名（literal name）。本宏是一個過時的宏。
宏： AC_SEARCH_LIBS (function, search-libs [, action-if-found [, action-if-not-found [, other-libraries]]])
如果function還不可用，就尋找一個定義了function的庫。這等同於首先不帶庫調用 AC_TRY_LINK_FUNC，而後爲每個在search-libs中列舉的庫調用AC_TRY_LINK_FUNC。
如果找到了函數，就運行action-if-found。否則運行action-if-not-found。
如果與庫library的連接導致了未定義符號錯誤，而這些錯誤可以通過與附加的庫進行連接來解決，就把這些庫用空格分隔，並作爲other-libraries參數給出：`-lXt -lX11'。否則，本宏對function 是否存在的檢測將總是失敗，這是因爲對測試程序的連接將總是因爲含有未定義符號錯誤而失敗。
宏： AC_SEARCH_LIBS (function, search-libs[, action-if-found [, action-if-not-found]])
本宏等價於爲每個在search-libs中列舉的庫調用一次AC_TRY_LINK_FUNC。爲找到的第一個含有 function的庫，把`-llibrary'添加到LIBS中，並且執行 action-if-found。否則就執行action-if-not-found。
庫函數
以下的宏用於檢測特定的C庫函數。如果沒有爲你需要的函數定義特定的宏，而且你不需要檢查它的任何特殊性質，那麼你可以使用一個通用函數檢測宏。
對特定函數的檢查
這些宏用於檢測特定的C函數--它們是否存在，以及在某些情況下，當給出了特定的參數時，它們是如何響應的。
宏： AC_FUNC_ALLOCA
檢測如何獲得alloca。本宏試圖通過檢查`alloca.h'或者預定義C預處理器宏 __GNUC__和_AIX來獲得alloca的內置（builtin）版本。如果本宏找到了`alloca.h'，它就定義HAVE_ALLOCA_H。
如果上述嘗試失敗了，本宏就在標準C庫中尋找函數。如果下列任何方法成功了，本宏就定義HAVE_ALLOCA。否則，它把輸出變量ALLOCA設置成`alloca.o'並且定義C_ALLOCA （這樣程序就可以週期性地調用`alloca(0)'以進行垃圾的收集）。本變量是從LIBOBJS中分離出來的，因此在只有一部分程序使用LIBOBJS中的代碼時，多個程序就可以不必創建實際的庫而共享ALLOCA的值。
本宏並不試圖從System V R3的`libPW'中，或者從System V R4的`libucb'中獲取alloca，這是因爲這些庫包含了一些造成麻煩的不兼容的函數。有些版本甚至不含有alloca或者含有帶bug的版本。如果你仍然需要使用它們的alloca，用ar把`alloca.o'從這些庫中提取出來，而不是編譯`alloca.c'。
使用alloca的源文件應該以如下一段代碼開頭，以正確地聲明它。在某些AIX版本中，對alloca 的聲明必須在除了註釋和預處理指令之前的任何東西之前出現。#pragma指令被縮進（indented），以便讓預標準C編譯器（pre-ANSI C compiler）忽略它，而不是導致錯誤（choke on it）。
/* AIX requires this to be the first thing in the file. */
#ifndef __GNUC__
# if HAVE_ALLOCA_H
# include
# else
# ifdef _AIX
#pragma alloca
# else
# ifndef alloca /* predefined by HP cc +Olibcalls */
char *alloca ();
# endif
# endif
# endif
#endif
宏： AC_FUNC_CLOSEDIR_VOID
如果函數closedir不返回有意義的值，就定義CLOSEDIR_VOID。否則，調用者就應該把它的返回值作爲錯誤指示器來進行檢查。
宏： AC_FUNC_FNMATCH
如果可以使用fnmatch函數，並且能夠工作（不象SunOS 5.4中的fnmatch那樣），就定義HAVE_FNMATCH。
宏： AC_FUNC_GETLOADAVG
檢查如何才能獲得系統平均負載。如果系統含有getloadavg函數，本宏就定義HAVE_GETLOADAVG，並且把爲了獲得該函數而需要的庫添加到LIBS中。
否則，它就把`getloadavg.o'添加到輸出變量LIBOBJS之中，並且可能定義幾個其他的C預處理器宏和輸出變量：
如果在相應的系統中，就根據系統類型定義宏SVR4、DGUX、UMAX或者UMAX4_3。
如果它找到了`nlist.h'，就定義NLIST_STRUCT。
如果結構`struct nlist'含有成員`n_un'，就定義NLIST_NAME_UNION。
如果在編譯`getloadavg.c'時定義了LDAV_PRIVILEGED，爲了使getloadavg能夠工作，程序就必須特殊地安裝在系統中，並且本宏定義GETLOADAVG_PRIVILEGED。
本宏設置輸出變量NEED_SETGID。如果需要進行特別的安裝，它的值就是`true'，否則值就是`false'。如果NEED_SETGID爲`true'，本宏把KMEM_GROUP 設置成將擁有被安裝的程序的組（group）的名字。
宏： AC_FUNC_GETMNTENT
爲Irix 4、PTX和Unixware在庫`sun'、`seq'和`gen'中分別查找getmntent函數。那麼，如果可以使用getmntent，就定義HAVE_GETMNTENT。
宏： AC_FUNC_GETPGRP
如果getpgrp不接受參數（POSIX.1版），就定義GETPGRP_VOID。否則，它就是一個把進程ID作爲參數的BSD版本。本宏根本不檢查getpgrp是否存在；如果你需要檢查它的存在性，就首先爲 getpgrp函數調用AC_CHECK_FUNC。
宏： AC_FUNC_MEMCMP
如果不能使用memcmp函數，或者不能處理8位數據（就像SunOS 4.1.3中的那樣），就把`memcmp.o' 添加到輸出變量LIBOBJS中去。
宏： AC_FUNC_MMAP
如果函數mmap存在並且能夠正確地工作，就定義HAVE_MMAP。只檢查已經映射（already-mapped）的內存的私有固定映射（private fixed mapping）。
宏： AC_FUNC_SELECT_ARGTYPES
確定函數select的每個參數的正確類型，並且把這些類型分別定義成SELECT_TYPE_ARG1、 SELECT_TYPE_ARG234和SELECT_TYPE_ARG5。SELECT_TYPE_ARG1的缺省值是`int'，SELECT_TYPE_ARG234的缺省值是`int *'， SELECT_TYPE_ARG5的缺省值是`struct timeval *'。
宏： AC_FUNC_SETPGRP
如果setpgrp不接受參數（POSIX.1版），就定義SETPGRP_VOID。否則，該函數就是一個把兩個進程ID作爲參數的BSD版本。本宏並不檢查函數setpgrp是否存在；如果你需要檢查該函數的存在性，就首先爲setpgrp調用AC_CHECK_FUNC。
宏： AC_FUNC_SETVBUF_REVERSED
如果函數setvbuf的第二個參數是緩衝區的類型並且第三個參數是緩衝區指針，而不是其他形式，就定義SETVBUF_REVERSED。這是在System V第3版以前的情況。
宏： AC_FUNC_STRCOLL
如果函數strcoll存在並且可以正確地工作，就定義HAVE_STRCOLL。由於有些系統包含了錯誤定義的strcoll，這時就不應該使用strcoll，因此本宏要比`AC_CHECK_FUNCS(strcoll)'多作一些檢查。
宏： AC_FUNC_STRFTIME
對於SCO UNIX，在庫`intl'中查找strftime。而後，如果可以使用strftime，就定義HAVE_STRFTIME。
宏： AC_FUNC_UTIME_NULL
如果`utime(file, NULL)'把file的時間標記設置成現在，就定義 HAVE_UTIME_NULL。
宏： AC_FUNC_VFORK
如果找到了`vfork.h'，就定義HAVE_VFORK_H。如果找不到可以工作的vfork，就把vfork定義成fork。本宏檢查一些已知的vfork實現中的錯誤並且認爲如果vfork的實現含有任何一個錯誤，系統就不含有可以工作的vfork。由於子進程很少改變它們的信號句柄（signal handler），所以如果子進程的signal調用（invocation）修改了父進程的信號句柄，將不會被當作實現的錯誤。
宏： AC_FUNC_VPRINTF
如果找到了vprintf，就定義HAVE_VPRINTF。否則，如果找到了_doprnt，就定義HAVE_DOPRNT。（如果可以使用vprintf，你就可以假定也可以使用vfprintf 和vsprintf。）
宏： AC_FUNC_WAIT3
如果找到了wait3並且該函數填充它的第三個參數的內容（`struct rusage *'），就定義HAVE_WAIT3。在HP-UX中，該函數並不這樣做。
對普通函數的檢查
這些宏被用於尋找沒有包括在特定函數測試宏中的函數。如果函數可能出現在除了缺省C庫以外的庫中，就要首先爲這些庫調用AC_CHECK_LIB。如果你除了需要檢查函數是否存在之外，還要檢查函數的行爲，你就不得不爲此而編寫你自己的測試（參見編寫測試）。
宏： AC_CHECK_FUNC (function, [action-if-found [, action-if-not-found]])
如果可以使用C函數function，就運行shell命令action-if-found，否則運行 action-if-not-found。如果你只希望在函數可用的時候定義一個符號，就考慮使用 AC_CHECK_FUNCS。由於C++比C更加標準化，即使在調用了AC_LANG_CPLUSPLUS 的時候，本宏仍然用C的連接方式對函數進行檢查。（關於爲測試選擇語言的詳情，請參見 對語言的選擇）
宏： AC_CHECK_FUNCS (function... [, action-if-found [, action-if-not-found]])
對於每個在以空格分隔的函數列表function中出現的函數，如果可用，就定義HAVE_function （全部大寫）。如果給出了action-if-found，它就是在找到一個函數的時候執行的附加的shell代碼。你可以給出 `break'以便在找到第一個匹配的時候跳出循環。如果給出了action-if-not-found，它就在找不到某個函數的時候執行。 網管聯盟bitsCN_com
宏： AC_REPLACE_FUNCS (function...)
本宏的功能就類似於以將`function.o'添加到輸出變量LIBOBJS的shell 代碼爲參數action-if-not-found，調用AC_CHECK_FUNCS。你可以通過用 `#ifndef HAVE_function'包圍你爲函數提供的替代版本的原型來聲明函數。如果系統含有該函數，它可能在一個你應該引入的頭文件中進行聲明，所以你不應該重新聲明它，以避免聲明衝突。
頭文件
下列宏檢查某些C頭文件是否存在。如果沒有爲你需要檢查的頭文件定義特定的宏，而且你不需要檢查它的任何特殊屬性，那麼你就可以使用一個通用的頭文件檢查宏。
對特定頭文件的檢查
這些宏檢查特定的系統頭文件--它們是否存在，以及在某些情況下它們是否定義了特定的符號。
宏： AC_DECL_SYS_SIGLIST
如果在系統頭文件，`signal.h'或者`unistd.h'，中定義了變量sys_siglist，就定義SYS_SIGLIST_DECLARED。
宏： AC_DIR_HEADER
類似於調用AC_HEADER_DIRENT和AC_FUNC_CLOSEDIR_VOID，但爲了指明找到了哪個頭文件而定義了不同的一組C預處理器宏。本宏和它定義的名字是過時的。它定義的名字是：
`dirent.h'
DIRENT
網管u家u.bitsCN.com
這些宏被用於尋找沒有包括在特定函數測試宏中的函數。如果函數可能出現在除了缺省C庫以外的庫中，就要首先爲這些庫調用AC_CHECK_LIB。如果你除了需要檢查函數是否存在之外，還要檢查函數的行爲，你就不得不爲此而編寫你自己的測試（參見編寫測試）。
宏： AC_CHECK_FUNC (function, [action-if-found [, action-if-not-found]])
如果可以使用C函數function，就運行shell命令action-if-found，否則運行 action-if-not-found。如果你只希望在函數可用的時候定義一個符號，就考慮使用 AC_CHECK_FUNCS。由於C++比C更加標準化，即使在調用了AC_LANG_CPLUSPLUS 的時候，本宏仍然用C的連接方式對函數進行檢查。（關於爲測試選擇語言的詳情，請參見 對語言的選擇）
宏： AC_CHECK_FUNCS (function... [, action-if-found [, action-if-not-found]])
對於每個在以空格分隔的函數列表function中出現的函數，如果可用，就定義HAVE_function （全部大寫）。如果給出了action-if-found，它就是在找到一個函數的時候執行的附加的shell代碼。你可以給出 `break'以便在找到第一個匹配的時候跳出循環。如果給出了action-if-not-found，它就在找不到某個函數的時候執行。 網管聯盟bitsCN_com
宏： AC_REPLACE_FUNCS (function...)
本宏的功能就類似於以將`function.o'添加到輸出變量LIBOBJS的shell 代碼爲參數action-if-not-found，調用AC_CHECK_FUNCS。你可以通過用 `#ifndef HAVE_function'包圍你爲函數提供的替代版本的原型來聲明函數。如果系統含有該函數，它可能在一個你應該引入的頭文件中進行聲明，所以你不應該重新聲明它，以避免聲明衝突。
頭文件
下列宏檢查某些C頭文件是否存在。如果沒有爲你需要檢查的頭文件定義特定的宏，而且你不需要檢查它的任何特殊屬性，那麼你就可以使用一個通用的頭文件檢查宏。
對特定頭文件的檢查
這些宏檢查特定的系統頭文件--它們是否存在，以及在某些情況下它們是否定義了特定的符號。
宏： AC_DECL_SYS_SIGLIST
如果在系統頭文件，`signal.h'或者`unistd.h'，中定義了變量sys_siglist，就定義SYS_SIGLIST_DECLARED。
宏： AC_DIR_HEADER
類似於調用AC_HEADER_DIRENT和AC_FUNC_CLOSEDIR_VOID，但爲了指明找到了哪個頭文件而定義了不同的一組C預處理器宏。本宏和它定義的名字是過時的。它定義的名字是：
`dirent.h'
DIRENT
網管u家u.bitsCN.com
`sys/ndir.h'
SYSNDIR
`sys/dir.h'
SYSDIR
`ndir.h'
NDIR
此外，如果closedir不能返回一個有意義的值，就定義VOID_CLOSEDIR。
宏： AC_HEADER_DIRENT
對下列頭文件進行檢查，並且爲第一個找到的頭文件定義`DIR'，以及列出的C預處理器宏：
`dirent.h'
HAVE_DIRENT_H
`sys/ndir.h'
HAVE_SYS_NDIR_H
`sys/dir.h'
HAVE_SYS_DIR_H
`ndir.h'
HAVE_NDIR_H
源代碼中的目錄庫聲明應該以類似於下面的方式給出：
#if HAVE_DIRENT_H
# include
# define NAMLEN(dirent) strlen((dirent)->d_name)
#else
# define dirent direct
# define NAMLEN(dirent) (dirent)->d_namlen
# if HAVE_SYS_NDIR_H
# include
# endif
# if HAVE_SYS_DIR_H
# include
# endif
# if HAVE_NDIR_H
# include
# endif
#endif
使用上述聲明，程序應該把變量定義成類型struct dirent，而不是struct direct，並且應該通過把指向struct direct的指針傳遞給宏NAMLEN來獲得目錄項的名稱的長度。
網管u家u.bitsCN.com
SYSNDIR
`sys/dir.h'
SYSDIR
`ndir.h'
NDIR
此外，如果closedir不能返回一個有意義的值，就定義VOID_CLOSEDIR。
宏： AC_HEADER_DIRENT
對下列頭文件進行檢查，並且爲第一個找到的頭文件定義`DIR'，以及列出的C預處理器宏：
`dirent.h'
HAVE_DIRENT_H
`sys/ndir.h'
HAVE_SYS_NDIR_H
`sys/dir.h'
HAVE_SYS_DIR_H
`ndir.h'
HAVE_NDIR_H
源代碼中的目錄庫聲明應該以類似於下面的方式給出：
#if HAVE_DIRENT_H
# include
# define NAMLEN(dirent) strlen((dirent)->d_name)
#else
# define dirent direct
# define NAMLEN(dirent) (dirent)->d_namlen
# if HAVE_SYS_NDIR_H
# include
# endif
# if HAVE_SYS_DIR_H
# include
# endif
# if HAVE_NDIR_H
# include
# endif
#endif
使用上述聲明，程序應該把變量定義成類型struct dirent，而不是struct direct，並且應該通過把指向struct direct的指針傳遞給宏NAMLEN來獲得目錄項的名稱的長度。
網管u家u.bitsCN.com
本宏還爲SCO Xenix檢查庫`dir'和`x'。
宏： AC_HEADER_MAJOR
如果`sys/types.h'沒有定義major、minor和makedev，但`sys/mkdev.h'定義了它們，就定義MAJOR_IN_MKDEV；否則，如果`sys/sysmacros.h'定義了它們，就定義MAJOR_IN_SYSMACROS。
宏： AC_HEADER_STDC
如果含有標準C（ANSI C）頭文件，就定義STDC_HEADERS。特別地，本宏檢查`stdlib.h'、`stdarg.h'、`string.h'和`float.h'；如果系統含有這些頭文件，它可能也含有其他的標準C頭文件。本宏還檢查`string.h'是否定義了memchr （並據此對其他mem函數做出假定），`stdlib.h'是否定義了free（並據此對malloc和其他相關函數做出假定），以及`ctype.h'宏是否按照標準C的要求而可以用於被設置了高位的字符。
因爲許多含有GCC的系統並不含有標準C頭文件，所以用STDC_HEADERS而不是__STDC__ 來決定系統是否含有服從標準（ANSI-compliant）的頭文件（以及可能的C庫函數）。
在沒有標準C頭文件的系統上，變種太多，以至於可能沒有簡單的方式對你所使用的函數進行定義以使得它們與系統頭文件聲明的函數完全相同。某些系統包含了ANSI和BSD函數的混合；某些基本上是標準（ANSI）的，但缺少`memmove'；有些系統在`string.h'或者`strings.h'中以宏的方式定義了BSD函數；有些系統除了含有`string.h'之外，只含有BSD函數；某些系統在`memory.h' 中定義內存函數，有些在`string.h'中定義；等等。對於一個字符串函數和一個內存函數的檢查可能就夠了；如果庫含有這些函數的標準版，那麼它就可能含有其他大部分函數。如果你在`configure.in' 中安放了如下代碼：
網管u家u.bitsCN.com
AC_HEADER_STDC
AC_CHECK_FUNCS(strchr memcpy)
那麼，在你的代碼中，你就可以像下面那樣放置聲明：
#if STDC_HEADERS
# include
#else
# ifndef HAVE_STRCHR
# define strchr index
# define strrchr rindex
# endif
char *strchr (), *strrchr ();
# ifndef HAVE_MEMCPY
# define memcpy(d, s, n) bcopy ((s), (d), (n))
# define memmove(d, s, n) bcopy ((s), (d), (n))
# endif
#endif
如果你使用沒有等價的BSD版的函數，諸如memchr、memset、strtok 或者strspn，那麼僅僅使用宏就不夠了；你必須爲每個函數提供一個實現。以memchr爲例，一種僅僅在需要的時候（因爲系統C庫中的函數可能經過了手工優化）與你的實現協作的簡單方式是把實現放入 `memchr.c'並且使用`AC_REPLACE_FUNCS(memchr)'。
宏： AC_HEADER_SYS_WAIT
如果`sys/wait.h'存在並且它和POSIX.1相兼容，就定義HAVE_SYS_WAIT_H。如果`sys/wait.h'不存在，或者如果它使用老式BSD union wait，而不是 int來儲存狀態值，就可能出現不兼容。如果`sys/wait.h'不與POSIX.1兼容，那就不是引入該頭文件，而是按照它們的常見解釋定義POSIX.1宏。下面是一個例子：
網管bitscn_com
#include
#if HAVE_SYS_WAIT_H
# include
#endif
#ifndef WEXITSTATUS
# define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
#endif
#ifndef WIFEXITED
# define WIFEXITED(stat_val) (((stat_val) & 255) == 0)
#endif
宏： AC_MEMORY_H
在`string.h'中，如果沒有定義memcpy, memcmp等函數，並且`memory.h' 存在，就定義NEED_MEMORY_H。本宏已經過時；可以用AC_CHECK_HEADERS(memory.h)來代替。參見爲AC_HEADER_STDC提供的例子。
宏： AC_UNISTD_H
如果系統含有`unistd.h'，就定義HAVE_UNISTD_H。本宏已經過時；可以用 `AC_CHECK_HEADERS(unistd.h)'來代替。
檢查系統是否支持POSIX.1的方式是：
#if HAVE_UNISTD_H
# include
# include
#endif
#ifdef _POSIX_VERSION
/* Code for POSIX.1 systems. */
#endif
在POSIX.1系統中包含了`unistd.h'的時候定義_POSIX_VERSION。如果系統中沒有`unistd.h'，那麼該系統就一定不是POSIX.1系統。但是，有些非POSIX.1（non-POSIX.1）系統也含有`unistd.h'。 網管bitscn_com
宏： AC_USG
如果系統並不含有`strings.h'、rindex、bzero等頭文件或函數，就定義USG。定義USG就隱含地表明瞭系統含有`string.h'、strrchr、memset等頭文件或函數。
符號USG已經過時了。作爲本宏的替代，參見爲AC_HEADER_STDC提供的例子。
對普通頭文件的檢查
這些宏被用於尋找沒有包括在特定測試宏中的系統頭文件。如果你除了檢查頭文件是否存在之外還要檢查它的內容，你就不得不爲此而編寫你自己的測試（參見編寫測試）。
宏： AC_CHECK_HEADER (header-file, [action-if-found [, action-if-not-found]])
如果系統頭文件header-file存在，就執行shell命令action-if-found，否則執行action-if-not-found。如果你只需要在可以使用頭文件的時候定義一個符號，就考慮使用 AC_CHECK_HEADERS。
宏： AC_CHECK_HEADERS (header-file... [, action-if-found [, action-if-not-found]])
對於每個在以空格分隔的參數列表header-file出現的頭文件，如果存在，就定義 HAVE_header-file（全部大寫）。如果給出了action-if-found，它就是在找到一個頭文件的時候執行的附加shell代碼。你可以把`break'作爲它的值以便在第一次匹配的時候跳出循環。如果給出了action-if-not-found，它就在找不到某個頭文件的時候被執行。
網管論壇bbs_bitsCN_com
結構
以下的宏檢查某些結構或者某些結構成員。爲了檢查沒有在此給出的結構，使用AC_EGREP_CPP （參見檢驗聲
編寫測試
如果現有的特徵測試不能完成你所需要的工作，你就必須編寫一個新的。這些宏是創建模塊。它們爲其它宏提供了檢查各種特徵是否存在並且報告結果的方式。
本章包括一些建議和一些關於現有的測試的爲什麼要那樣編寫的原因。通過閱讀現有的測試，你還可以學到許多關於編寫 Autoconf測試的方法。如果在一個或多個Autoconf測試中出現了錯誤，這些信息可以幫助你理解它們意味着什麼，這有助於你找到最佳的解決問題的辦法。
這些宏檢查C編譯器系統的輸出。它們並不爲未來的使用而緩存測試的結果（參見緩存結果），這是因爲它們沒有足夠的信息以生成緩存變量名。基於同樣的原因，它們還不會輸出任何消息。對特殊的C的特徵進行的測試調用這些宏並且緩存它們的結果、打印關於它們所進行的測試的消息。
當你編寫了一個可以適用於多於一個軟件包的特徵測試時，最好的方式就是用一個新宏封裝它。關於如何封裝，參見 編寫宏。
檢驗聲明
宏AC_TRY_CPP用於檢測某個特定的頭文件是否存在。你可以一次檢查一個頭文件，或者如果你爲了某些目的而希望多個頭文件都存在，也可以一次檢查多個頭文件。
宏： AC_TRY_CPP (includes, [action-if-true [, action-if-false]])
中國網管論壇bbs.bitsCN.com
如果現有的特徵測試不能完成你所需要的工作，你就必須編寫一個新的。這些宏是創建模塊。它們爲其它宏提供了檢查各種特徵是否存在並且報告結果的方式。
本章包括一些建議和一些關於現有的測試的爲什麼要那樣編寫的原因。通過閱讀現有的測試，你還可以學到許多關於編寫 Autoconf測試的方法。如果在一個或多個Autoconf測試中出現了錯誤，這些信息可以幫助你理解它們意味着什麼，這有助於你找到最佳的解決問題的辦法。
這些宏檢查C編譯器系統的輸出。它們並不爲未來的使用而緩存測試的結果（參見緩存結果），這是因爲它們沒有足夠的信息以生成緩存變量名。基於同樣的原因，它們還不會輸出任何消息。對特殊的C的特徵進行的測試調用這些宏並且緩存它們的結果、打印關於它們所進行的測試的消息。
當你編寫了一個可以適用於多於一個軟件包的特徵測試時，最好的方式就是用一個新宏封裝它。關於如何封裝，參見 編寫宏。
檢驗聲明
宏AC_TRY_CPP用於檢測某個特定的頭文件是否存在。你可以一次檢查一個頭文件，或者如果你爲了某些目的而希望多個頭文件都存在，也可以一次檢查多個頭文件。
宏： AC_TRY_CPP (includes, [action-if-true [, action-if-false]])
中國網管論壇bbs.bitsCN.com
includes是C或C++的#include語句和聲明，對於它，將進行shell變量、反引用（backquote）、以及反斜線（backslash）替換。（實際上，它可以是任何C程序，但其它的語句可能沒有用。）如果預處理器在處理它的時候沒有報告錯誤，就運行shell命令action-if-true。否則運行shell命令action-if-false。
本宏使用CPPFLAGS，而不使用CFLAGS，這是因爲`-g'、`-O'等選項對於許多C預處理器來說都是不合法的選項。
下面是如何確認在某個頭文件中是否包含一個特定的聲明，比如說typedef、結構、結構成員或者一個函數。使用 AC_EGREP_HEADER而不是對頭文件直接運行grep；在某些系統中，符號可能是在另一個你所檢查的 `#include'文件。
宏： AC_EGREP_HEADER (pattern, header-file, action-if-found [, action-if-not-found])
如果對系統頭文件header-file運行預處理器所產生的輸出與egrep常規表達式pattern相匹配，就執行shell命令action-if-found，否則執行action-if-not-found。
爲了檢查由頭文件或者C預處理器預定義的C預處理器符號，使用AC_EGREP_CPP。下面是後者的一個例子：
AC_EGREP_CPP(yes,
[#ifdef _AIX
yes 中國網管論壇bbs.bitsCN.com
#endif
], is_aix=yes, is_aix=no)
宏： AC_EGREP_CPP (pattern, program, [action-if-found [, action-if-not-found]])
program是C或者C++的程序文本，對於它，將進行shell變量、反引號（backquote）以及反斜線（backslash）替換。如果對program運行預處理器產生的輸出與egrep常規表達式（regular expression）pattern 相匹配，就執行shell命令action-if-found，否則執行action-if-not-found。
如果宏還沒有調用AC_PROG_CPP或者AC_PROG_CXXCPP（根據當前語言來確定使用那個宏，參見對語言的選擇），本宏將調用它。
檢驗語法
爲了檢查C、C++或者Fortran 77編譯器的語法特徵，比如說它是否能夠識別某個關鍵字，就使用AC_TRY_COMPILE 來嘗試編譯一個小的使用該特徵的程序。你還可以用它檢查不是所有系統都支持的結構和結構成員。
宏： AC_TRY_COMPILE (includes, function-body, [action-if-found [, action-if-not-found]])
創建一個C、C++或者Fortran 77測試程序（依賴於當前語言，參見對語言的選擇），來察看由function-body組成的函數是否可以被編譯。
對於C和C++，includes是所有function-body中的代碼需要的#include語句（如果當前選擇的語言是Fortran 77，includes將被忽略）。如果當前選擇的語言是C或者C++，本宏還將在編譯的時侯使用CFLAGS或者CXXFLAGS，以及CPPFLAGS。如果當前選擇的語言是Fortran 77，那麼就在編譯的時候使用FFLAGS。
如果文件被成功地編譯了，就運行shell命令action-if-found，否則運行action-if-not-found。
本宏並不試圖進行連接；如果你希望進行連接，使用AC_TRY_LINK （參見檢驗庫）。
檢驗庫
爲了檢查一個庫、函數或者全局變量，Autoconf configure腳本試圖編譯並連接一個使用它的小程序。不像Metaconfig，它在缺省情況下對C庫使用nm或者ar以試圖確認可以使用那個函數。由於與函數相連接避免了處理nm和ar的各個變種的選項及輸出格式，而且不必處理標準庫的位置，所以與函數連接通常是更加可靠的辦法。如果需要，它還允許進行交叉配置或者檢查函數的運行是特徵。另一方面，它比一次性掃描庫要慢一些。
少數系統的連接器在出現找不到的函數錯誤（unresolved functions）時不返回失敗的退出狀態。這個錯誤使得由Autoconf 生成的配置腳本不能在這樣的系統中使用。然而，有些這樣的連接器允許給出選項以便正確地返回錯誤狀態。 Autoconf目前還不能自動地處理這個問題。如果用戶遇到了這樣的問題，他們可能可以通過在環境中設置LDFLAGS 以把連接器所需要的選項（例如，`-Wl,-dn' on MIPS RISC/OS）傳遞給連接器，從而解決這個問題。
AC_TRY_LINK用於編譯測試程序，以測試函數和全局變量。AC_CHECK_LIB還用本宏把被測試的庫暫時地加入LIBS並試圖連接一個小程序，從而對庫進行檢查（參見庫文件）。 網管下載dl.bitscn.com
宏： AC_TRY_LINK (includes, function-body, [action-if-found [, action-if-not-found]])
根據當前語言（參見對語言的選擇），創建一個測試程序以察看一個函數體爲function-body的函數是否可以被編譯和連接。
對C和C++來說，includes給出了所有function-body中的代碼需要的#include語句（如果當前選定的語言是Fortran 77，includes將被忽略）。如果當前語言是C或者C++，本宏在編譯時還將使用 CFLAGS或者CXXFLAGS，以及CPPFLAGS。如果當前選定的語言是Fortran 77，那麼在編譯時將使用FFLAGS。然而，在任何情況下，連接都將使用LDFLAGS和LIBS。
如果文件被成功地編譯和連接了，就運行shell命令action-if-found，否則就運行action-if-not-found。
宏： AC_TRY_LINK_FUNC (function, [action-if-found [, action-if-not-found]])
根據當前語言（參見對語言的選擇），創建一個測試程序以察看一個含有function 原型和對它的調用的程序是否可以被編譯和連接。
如果文件被成功地編譯和連接了，就運行shell命令action-if-found，否則就運行action-if-not-found。
宏： AC_TRY_LINK_FUNC (function, [action-if-found [, action-if-not-found]]) 網管u家u.bitscn@com
試圖編譯並且連接一個與function相連接的小程序。如果文件被成功地編譯和連接了，就運行shell命令 action-if-found，否則就運行action-if-not-found。
宏： AC_COMPILE_CHECK (echo-text, includes, function-body, action-if-found [, action-if-not-found])
本宏是AC_TRY_LINK的一個過時的版本。此外，如果echo-text不爲空，它首先還要把 `checking for echo-text'打印到標準輸出。用AC_MSG_CHECKING 和AC_MSG_RESULT來代替本宏的打印消息的功能（參見打印消息）。
檢驗運行時的特徵
有時候，你需要知道系統在運行時作了些什麼，比如說某個給定的函數是否具備某種能力或者是否含有錯誤。如果你能，你可以在你的程序初始化時自行檢查這類事件（比如說machine's endianness）。
如果你實在需要在配置時刻檢查運行時的特徵，你可以編寫一個測試程序以確定結果，並且通過AC_TRY_RUN 來編譯和運行它。如果可能就避免運行測試程序，這是因爲使用它們使得人們不能對你的包進行交叉編譯。
運行測試程序
如果你希望在配置的時候測試系統運行時的特徵，就使用如下的宏。
宏： AC_TRY_RUN (program, [action-if-true [, action-if-false [, action-if-cross-compiling]]]) 網管下載dl.bitscn.com
program是C程序的文本，將對該文本進行shell變量和反引用（backquote）替換。如果它被成功地編譯和連接了並且在執行的時候返回的退出狀態爲0，就運行shell命令action-if-true。否則就運行shell命令action-if-false；程序的退出狀態可以通過shell變量`$?'得到。本宏在編譯時使用CFLAGS或者CXXFLAGS以及 CPPFLAGS、LDFLAGS和LIBS。
如果使用的C編譯器生成的不是在configure運行的系統上運行的可執行文件，那麼測試程序就不運行。如果給出了可選的shell命令action-if-cross-compiling，它們就代替生成的可執行文件執行。否則， configure打印一條錯誤消息並且退出。
當交叉編譯使運行時測試變得不可能的時候，就嘗試提供一個應急（pessimistic）的缺省值以供使用。你通過把可選的最後一個參數傳遞給AC_TRY_RUN來完成這個工作。在每次生成configure的過程中，每次遇到沒有提供 action-if-cross-compiling參數的AC_TRY_RUN調用時，autoconf都打印一條警告消息。雖然用戶將不能爲交叉編譯你的包而進行配置，你仍可以忽略該警告。與Autoconf一同發行的少數宏產生該警告消息。
爲了爲交叉編譯進行配置，你還可以根據規範系統名（canonical system name）爲這些參數選擇值（參見手工配置）。另一種方式是把測試緩存文件設置成目標系統的正確值（參見緩存結果）。
網管bitscn_com
爲了給嵌入到其它宏（包括少數與Autoconf一同發行的宏）中的，對AC_TRY_RUN的調用提供缺省值，你可以在它們運行之前調用AC_PROG_CC。那麼，如果shell變量cross_compiling被設置成 `yes'，就AC_DEFINE(EQUATION, "$a > $b")
宏： AC_DEFINE_UNQUOTED (variable [, value [, description]])
類似於AC_DEFINE，但還要對variable和value進行三種shell替換（每種替換隻進行一次）：變量擴展（`$'），命令替換（``'），以及反斜線傳義符（`\'）。值中的單引號和雙引號沒有特殊的意義。在variable或者value是一個shell變量的時候用本宏代替AC_DEFINE。例如：
AC_DEFINE_UNQUOTED(config_machfile, "${machfile}")
AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups)
AC_DEFINE_UNQUOTED(${ac_tr_hdr})
由於Bourne shell在語法上的特異性，不要用分號來分隔對AC_DEFINE或者AC_DEFINE_UNQUOTED的調用和其它的宏調用或者shell代碼；這將在最終的configure腳本中導致語法錯誤。你既可以使用空格，也可以使用換行。就是這樣：
AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4) LIBS="$LIBS -lelf")
或者：
AC_CHECK_HEADER(elf.h,
AC_DEFINE(SVR4)
LIBS="$LIBS -lelf")
而不是：
AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4); LIBS="$LIBS -lelf")
網管聯盟bitsCN@com
設置輸出變量
記錄測試結果的一種方式是設置輸出變量，該變量是shell變量，它的值將被替換到configure輸出的文件中。下面的兩個宏創建新的輸出變量。關於總是可用的輸出變量的列表，參見預定義輸出變量。
宏： AC_SUBST (variable)
從一個shell變量創建一個輸出變量。讓AC_OUTPUT把變量variable替換到輸出文件中（通常是一個或多個 `Makefile'）。這意味着AC_OUTPUT將把輸入文件中的`@variable@'實例替換成調用AC_OUTPUT時shell變量variable的值。variable的值不能包含新行。
宏： AC_SUBST_FILE (variable)
另一種從shell變量創建輸出變量的方式。讓AC_OUTPUT把由shell變量variable給出的文件名的文件的內容（不進行替換）插入到輸出文件中。這意味着AC_OUTPUT將在輸出文件中（比如`Makefile.in'）把輸入文件中的`@variable@'實例替換爲調用AC_OUTPUT時shell變量variable的值指明的文件的內容。如果沒有文件可以插入，就把變量設置成`/dev/null'。
本宏用於把包含特殊依賴性或者爲特殊主機或目標機準備的其它make指令的`Makefile'片斷插入 `Makefile'。例如，`configure.in'可以包含：
AC_SUBST_FILE(host_frag)dnl
中國網管論壇bbs.bitsCN.com
host_frag=$srcdir/conf/sun4.mh
那麼`Makefile.in'就應該包含：
@host_frag@
緩存結果
爲了避免在各種configure腳本中重複地對相同的特徵進行檢查（或者重複地運行同一個腳本）， configure把它的檢查的許多結果儲存在緩存文件。如果在configure腳本運行時，它找到了緩存文件，它就從中讀取從前運行的結果並且不再重新運行這些檢查。因此，configure將比每次都運行所有的檢查要快得多。
宏： AC_CACHE_VAL (cache-id, commands-to-set-it)
確認由cache-id指定的檢查的結果是可用的。如果檢查的結果在讀入的緩存文件中，並且configure 沒有用`--quiet'或者`--silent'調用，就打印一條消息以說明該結果已經被緩存了；否則，就運行 shell命令commands-to-set-it。這些命令不應具有副作用，但設置變量cache-id除外。它們尤其不應該調用 AC_DEFINE；緊隨與對AC_CACHE_VAL的調用之後的代碼應該根據緩存的值調用AC_DEFINE 作這件事。此外，它們不應該打印任何消息，比如說使用AC_MSG_CHECKING；應該在調用AC_CACHE_VAL 之前打印，以便不論測試的結果是從緩存中檢索而得到的，還是通過運行shell命令而確定的，都會打印消息。如果是運行 shell命令以確定值，該值將在configure創建它的輸出文件之前被儲存到緩存文件中。關於如何選擇 cache-id變量的名稱，參見緩存變量名。
網管聯盟bitsCN@com
宏： AC_CACHE_CHECK (message, cache-id, commands)
這是一個更詳盡地處理了打印消息的AC_CACHE_VAL版本。本宏爲這些宏的最常見的應用提供了便捷的縮寫。它爲message調用AC_MSG_CHECKING，而後以cache-id和commands爲參數調用AC_CACHE_VAL，最後以cache-id爲參數調用AC_MSG_RESULT。
宏： AC_CACHE_LOAD
從已經存在的緩存文件中裝入值，如果找不到緩存文件，就創建一個新的緩存文件。本宏由AC_INIT自動調用。
宏： AC_CACHE_SAVE
把所有緩存的值刷新到緩存文件中。本宏由AC_OUTPUT自動調用，但在configure.in的關鍵點調用 AC_CACHE_SAVE是十分有用的。假如配置腳本中途失敗（abort）了，這些關鍵點仍然可以緩存一部分結果。
緩存變量名
緩存變量的名字應該符合如下格式：
package-prefix_cv_value-type_specific-value[_additional-options]
例如，`ac_cv_header_stat_broken'或者`ac_cv_prog_gcc_traditional'。變量名的各個部分爲：
package-prefix
你的包或者組織的縮寫；除了爲了方便而使用小寫字母以外，與你使用的作爲本地Autoconf宏的開頭的前綴一樣。對於由發佈的Autoconf宏使用的緩存值，它是`ac'。
網管聯盟bitsCN_com
這是一個更詳盡地處理了打印消息的AC_CACHE_VAL版本。本宏爲這些宏的最常見的應用提供了便捷的縮寫。它爲message調用AC_MSG_CHECKING，而後以cache-id和commands爲參數調用AC_CACHE_VAL，最後以cache-id爲參數調用AC_MSG_RESULT。
宏： AC_CACHE_LOAD
從已經存在的緩存文件中裝入值，如果找不到緩存文件，就創建一個新的緩存文件。本宏由AC_INIT自動調用。
宏： AC_CACHE_SAVE
把所有緩存的值刷新到緩存文件中。本宏由AC_OUTPUT自動調用，但在configure.in的關鍵點調用 AC_CACHE_SAVE是十分有用的。假如配置腳本中途失敗（abort）了，這些關鍵點仍然可以緩存一部分結果。
緩存變量名
緩存變量的名字應該符合如下格式：
package-prefix_cv_value-type_specific-value[_additional-options]
例如，`ac_cv_header_stat_broken'或者`ac_cv_prog_gcc_traditional'。變量名的各個部分爲：
package-prefix
你的包或者組織的縮寫；除了爲了方便而使用小寫字母以外，與你使用的作爲本地Autoconf宏的開頭的前綴一樣。對於由發佈的Autoconf宏使用的緩存值，它是`ac'。
網管聯盟bitsCN_com
_cv_
表明本shell變量是一個緩存值。
value-type
關於緩存值類別的慣例，以生成一個合理的命名系統。在Autoconf中使用的值在宏名中列出。
specific-value
指明本測試應用於緩存值類的那個成員。例如，那個函數（`alloca'）、程序（`gcc'）或者輸出變量（`INSTALL'）。
additional-options
給出應用本測試的特定成員的任何特殊行爲。例如，`broken'或者`set'。如果沒有用，名字的這個部分可能被忽略掉。
賦予緩存變量的值不能含有新行。通常，它們的是將是布爾（`yes'或`no'）或者文件名或者函數名；所以，這並不是一個重要的限制。
緩存文件
緩存文件是一個緩存了在一個系統上進行配置測試的結果，以便在配置腳本和配置的運行之間共享的shell腳本。它對於其他系統來說是沒有用的。如果它的內容因爲某些原因而變得無效了，用戶可以刪除或者編輯它。
在缺省情況下，configure把`./config.cache'作爲緩存文件，如果它還不存在，就創建它。 configure接受選項`--cache-file=file'以使用不同的緩存文件；這就是configure在調用子目錄中的configure腳本時所作的工作。關於使用宏AC_CONFIG_SUBDIRS在子目錄中進行配置的信息，參見 在子目錄中配置其它包。 網管下載dl.bitscn.com
給出`--cache-file=/dev/null'會關閉緩存，這是爲調試configure提供的。只有在調用`config.status'時給出選項`--recheck'，這將導致它重新運行configure，它纔會注意到緩存文件。如果你預計需要一個長的調試時期，你還可以通過在`configure.in'的開頭重新定義緩存宏而關閉對configure腳本的裝入和儲存：
define([AC_CACHE_LOAD], )dnl
define([AC_CACHE_SAVE], )dnl
AC_INIT(whatever)
... rest of configure.in ...
試圖爲特定的系統類型發佈緩存文件是錯誤的。這裏存在太多的導致錯誤的空間，並帶來太多的用於維護它們的管理開銷。對於任何不能被自動猜測出來的特徵，應使用規範系統類型和連接文件的方法（參見手工配置）。
在特定系統中，每當有人運行configure腳本時，緩存文件將逐漸積累起來；緩存文件在一開始並不存在。運行configure會把新的緩存結果與現存的緩存文件結合起來。爲了讓它透明地工作，只要每次都使用相同的C編譯器，站點初始化（site initialization）腳本可以指定一個站點範圍（site-wide）的緩存文件以代替缺省的緩存文件。（參見設定本地缺省值）。
如果你的配置腳本，或者configure.in中的宏調用，偶爾導致配置過程的失敗，在幾個關鍵點進行緩存可能是有用的。在有希望修正導致上次運行的錯誤的時候，這樣做將減少重新運行configure腳本的時間。 網管網www_bitscn_com
... AC_INIT, etc. ...
dnl checks for programs
AC_PROG_CC
AC_PROG_GCC_TRADITIONAL
... more program checks ...
AC_CACHE_SAVE
dnl checks for libraries
AC_CHECK_LIB(nsl, gethostbyname)
AC_CHECK_LIB(socket, connect)
... more lib checks ...
AC_CACHE_SAVE
dnl Might abort...
AM_PATH_GTK(1.0.2, , exit 1)
AM_PATH_GTKMM(0.9.5, , exit 1)
打印消息
configure腳本需要爲運行它們的用戶提供幾種信息。下列的宏爲每種信息以適當的方式打印消息。所有宏的參數都應該由shell雙引號括起來，以便shell可以對它們進行變量替換和反引號替換。你可以把消息用 m4引用字符括起來以打印包含括號的消息：
AC_MSG_RESULT([never mind, I found the BASIC compiler])
這些宏都是對shell命令echo的封裝。configure應該很少需要直接運行echo來爲用戶打印消息。使用這些宏使得修改每種消息如何打印及何時打印變得容易了；這些修改只需要對宏的定義進行就行了，而所有的調用都將自動地改變。
宏： AC_MSG_CHECKING (feature-description)
網管論壇bbs_bitsCN_com
告知用戶configure正在檢查特定的特徵。本宏打印一條以`checking '開頭，以`...' 結尾，而且不帶新行的消息。它必須跟隨一條對AC_MSG_RESULT的調用以打印檢查的結果和新行。 feature-description應該是類似於 `whether the Fortran compiler accepts C++ comments'或者`for c89'的東西。
如果運行configure給出了選項`--quiet'或者選項`--silent'，獲取規範的系統類型
下列的宏使得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變量。 網管u家u.bitsCN.com
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應該是相對於頂層源代碼目錄或者創建目錄的相對路徑。可以多次調用本宏。
網管論壇bbs_bitsCN_com
例如,下列調用：
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'。
網管聯盟bitsCN_com
如果運行configure給出了選項`--quiet'或者選項`--silent'，獲取規範的系統類型
下列的宏使得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變量。 網管u家u.bitsCN.com
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應該是相對於頂層源代碼目錄或者創建目錄的相對路徑。可以多次調用本宏。
網管論壇bbs_bitsCN_com
例如,下列調用：
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'。
網管聯盟bitsCN_com
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。
網管網[url]www.bitscn.com[/url]
參數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'。 網管bitscn_com
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中相應的參數（參見與外部軟件一起工作）。 網管u家u.bitscn@com
宏： 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中。 網管論壇bbs_bitsCN_com
如果把下列任意選項傳遞給了configure,程序名就據此進行變換。否則,如果已經調用了AC_CANONICAL_SYSTEM並且`--target'的值給出了與主機類型（用`--host'給出的,或者是在config.sub中設置的缺省值）不同的類型,就把末尾附加了破折號的目標類型作爲前綴。否則,就不進行程序名變換。
轉換選項
我如何解開死結?
如果Autoconf需要GNU m4並且GNU m4還有一個Autoconf configure腳本，
我如何解開這個死結？它好像是一個類似於雞和蛋的問題！
這實際上是一種誤解。雖然GNU m4帶有一個由Autoconf生成的configure腳本，但在運行腳本及安裝GNU m4的時候並不需要安裝Autoconf。只有在你需要修改m4的configure 腳本的時候，這只是少數幾個人（主要是它的維護者）必須去作的事，才需要Autoconf。
爲什麼不使用Imake?
爲什麼不用Imake來代替configure腳本？
有些人已經提出了這個問題，所以在改編之後，我把給他們的解釋寫在這裏。
下面是對Richard Pixley的問題的回答：
由Autoconf生成的腳本經常地在它以前從未設置過的機器上工作。這就是說，它善於推斷新系統的配置。而Imake不能做到。
Imake使用含有主機特定數據的通用數據庫。對X11來說，這種方法具有意義是因爲發佈版本是由一個控制整個數據庫的總管機關管理的一組工具組成的。
GNU工具並不按這種方式發行。每個GNU工具都有一個維護者；這些維護者散佈在世界各地。使用統一的數據庫將使維護變成噩夢。 Autoconf可能成爲這類數據庫，但實際上它沒有。不是列舉主機的依賴性，它列舉的是程序的需求。
網管bitscn_com
如果Autoconf需要GNU m4並且GNU m4還有一個Autoconf configure腳本，
我如何解開這個死結？它好像是一個類似於雞和蛋的問題！
這實際上是一種誤解。雖然GNU m4帶有一個由Autoconf生成的configure腳本，但在運行腳本及安裝GNU m4的時候並不需要安裝Autoconf。只有在你需要修改m4的configure 腳本的時候，這只是少數幾個人（主要是它的維護者）必須去作的事，才需要Autoconf。
爲什麼不使用Imake?
爲什麼不用Imake來代替configure腳本？
有些人已經提出了這個問題，所以在改編之後，我把給他們的解釋寫在這裏。
下面是對Richard Pixley的問題的回答：
由Autoconf生成的腳本經常地在它以前從未設置過的機器上工作。這就是說，它善於推斷新系統的配置。而Imake不能做到。
Imake使用含有主機特定數據的通用數據庫。對X11來說，這種方法具有意義是因爲發佈版本是由一個控制整個數據庫的總管機關管理的一組工具組成的。
GNU工具並不按這種方式發行。每個GNU工具都有一個維護者；這些維護者散佈在世界各地。使用統一的數據庫將使維護變成噩夢。 Autoconf可能成爲這類數據庫，但實際上它沒有。不是列舉主機的依賴性，它列舉的是程序的需求。
網管bitscn_com
如果你把GNU套件看作一組本地工具，那麼問題就很相似了。但GNU開發工具可以作爲交叉工具（cross tools）而在幾乎所有主機+目標機的組合中進行配置。所有的這些配置都可以同時（concurrency）安裝。它們甚至可以被配置成可以在不同主機上共享與主機獨立的信息的形式。Imake不能處理這些問題。
Imake模板是標準的一種形式。GNU編碼標準在沒有強加相同的限制的情況下，解決了相同的問題。
下面是一些由Per Bothner撰寫的進一步的解釋：
Imake的一個長處是它易於通過使用cpp的`#include'和宏機制生成大的Makefile。然而，cpp是不可編程的：它含有有限的條件工具，而不含有循環。而且cpp不能檢查它的環境。
所有這些問題可以通過使用sh而不是cpp來解決。shell是完全可編程的、含有宏替換、可以執行（或者編制）其它的shell腳本，並且可以檢查它的環境。
Paul Eggert更詳細地闡述：
使用Autoconf，安裝者不必假定Imake自身已經被安裝並且正常地工作了。這對於習慣使用Imake的人們來說，看起來不是突出的長處。但在許多主機上，並沒有安裝Imake或者缺省的安裝不能很好地工作，爲此，要求安裝Imake就阻礙了在這些主機上使用由Imake配置的軟件包。例如，Imake模板和配置文件可能不能適當地安裝在一個主機上，或者Imake創建過程可能會錯誤地假定所有的源代碼文件都在一個大目錄樹中，或者Imake配置可能使用某個編譯器而包或者安裝器需要使用另一個編譯器，或者包需要的Imake的版本號與系統支持的版本號不匹配。這些問題在Autoconf中很少出現，這是因爲包附帶屬於它自己的獨立配置處理器。
網管bitscn_com
還有，Imake通常會在make和安裝者的C預處理器之間遇到難以預期的影響。這裏的基本問題是，C預處理器是爲處理C程序而不是`Makefile'而設計的。這對Autoconf來說問題小得多，它使用通用目的預處理器m4，並且包的作者（而不是安裝者）以標準的方式進行預處理。
最後，Mark Eichin解釋道：
Imake還不是完全可擴展的。爲了把新特徵添加到Imake中，你需要提供你自己的項目模板，並且複製已經存在的特徵的主要部分。這意味着對於複雜的項目來說，使用由買主提供的（vendor-provided）Imake模板不能提供任何平衡作用--這是因爲它們不包括你自己的項目的任何東西（除非它是一個X11程序）。
但是，另一方面：
一個Imake勝過configure的長處是： `Imakefile'總是趨向於比`Makefile.in'簡短（同樣地，冗餘較少）。但是，這兒有一個修正的方法--至少對於Kerberos V5樹來說，我們已經在整個樹中進行了修改以調用通用的 `post.in'和`pre.in' `Makefile'片斷。這意味着大部分通用的東西，即使它們通常是在configure中設置的，也不必複製。
從版本1中升級
Autoconf第2版基本上與第1版是向後兼容的。但是，它給出了作某些事的更好方法，並且不再支持版本1中一些醜陋的東西。因此，根據你的`configure.in'文件的複雜性，你可能必須作一些手工的工作以升級到版本2。本章指出了一些在升級的時候需要注意的問題。還有，可能你的configure腳本可以從版本2中的新特徵中獲得一些好處；在Autoconf發佈包中的`NEWS'文件概括了改變的部分。
網管網[url]www.bitscn.com[/url]
首先，確認你安裝了1.1版或者更高版本的GNU m4，最好是1.3版或者更高版本。在1.1版之前的版本含有bug 以至於它不能與Autoconf版本2一同工作。版本1.3及其後的版本比早期的版本更快一些，這是因爲1.3版的GNU m4 對轉換（diversions）進行了更有效的實現並且能夠在可以快速讀回的文件中凍結（freeze）它的內部狀態。
改變了的文件名
如果你隨Autoconf一起安裝了`aclocal.m4'（相對於特定軟件包的源代碼目錄中的`aclocal.m4'），你必須把它重命名爲`acsite.m4'。參見用autoconf創建configure。
如果你與你的軟件包一同發佈`install.sh'，就把它重命名爲`install-sh'以便make的內置規則不會無意地從該文件創建一個稱爲`install'的文件。AC_PROG_INSTALL將尋找這兩個名字的腳本，但最好使用新名字。
如果你使用`config.h.top'或者`config.h.bot'，你仍然可以使用它們，但如果你把它們混合到 `acconfig.h'之中，將減少你的麻煩。參見用autoheader創建`config.h.in'。
改變了的Makefile
在你的`Makefile.in'文件中添加`@CFLAGS@'、`@CPPFLAGS@'和`@LDFLAGS@'，以便它們可以在configure運行的時候利用環境中的這些變量的值。這樣做不是必須的，但對用戶來說比較方便。 網管論壇bbs_bitsCN_com
對於AC_OUTPUT的每個非`Makefile'的輸入文件，你還應該添加一條含有 `@configure_input@'的註釋，以便輸出文件將會包含一條註釋以說明它們是由configure生成的。自動地爲每種人們在AC_OUTPUT中輸出的文件選擇正確的註釋語法需要做太多的工作。
把`config.log'和`config.cache'添加到你要在distclean目標中刪除的文件的列表中。
如果你的`Makefile.in'如下：
prefix = /usr/local
exec_prefix = ${prefix}
你必須把它修改成：
prefix = @prefix@
exec_prefix = @exec_prefix@
不使用`@'字符的老式的對這些變量的替換行爲已經被刪除了。
改變了的宏
在Autoconf第2版中，重新命名了許多宏。你仍然可以使用舊名字，但新名字更清晰，並且易於找到相關文檔。關於爲舊宏名提供新宏名的列表，參見陳舊的宏名。用autoupdate程序轉換你的`configure.in'以使用新的宏名。參見用autoupdate更新configure。
有些宏已經被能夠更好地完成工作的類似宏所代替，但在調用上並不兼容。如果你在運行autoconf時受到了關於調用過時宏的警告，你可以安全地忽略它們，但如果你按照打印的建議替換過時的宏，你的configure腳本通常可以工作的更好。特別地，報告測試結果的機制已經改變了。如果你使用了echo或者AC_VERBOSE（可能是通過AC_COMPILE_CHECK），如果你改用AC_MSG_CHECKING和AC_MSG_RESULT，你的configure腳本的輸出將更加美觀。參見打印消息。這些宏能夠更好地與緩存變量協同工作。參見緩存結果。 網管下載dl.bitscn.com
用autoupdate更新configure
程序autoupdate把使用Autoconf舊宏名的`configure.in'文件更新爲使用當前宏名的文件。在Autoconf第2版中，大部分宏被重命名以使用一個更統一、更具有描述性的命名機制。關於對新的命名機制的描述，參見宏名。雖然舊宏名仍然可以工作（關於舊宏名和對應的新宏名的列表，參見陳舊的宏名），如果你更新它們以使用新的宏名，你可以使你的 `configure.in'文件更加可讀並且易於使用當前的Autoconf文檔。
如果沒有給出參數，autoupdate就更新`configure.in'，並且通過添加後綴`~' （或者在設置了環境變量SIMPLE_BACKUP_SUFFIX的時候，使用該環境變量的值）以備份原始版本。如果你帶參數調用autoupdate，它就讀入那個文件而不是讀入`configure.in'，並且把更新的文件輸出到標準輸出。
autoupdate接受下列選項：
--help
-h
打印命令行選項的概述並且退出。
--macrodir=dir
-m dir
在目錄dir中，而不是在缺省安裝目錄中尋找Autoconf宏文件。你還可以把環境變量AC_MACRODIR設置成一個目錄；本選項覆蓋該環境變量。
--version
打印autoupdate的版本號並且退出。 中國網管聯盟bitsCN.com
改變了的結果
如果你通過檢驗shell變量DEFS來檢驗以前測試的結果，你需要把這些檢驗替換爲對那些測試的緩存變量的檢查。在configure運行的時候，DEFS不再存在；它僅僅在生成輸出文件的時候才被創建。這種與第1版的不同是因爲正確地對變量實行引用（quoting）實在太麻煩而且在每次調用AC_DEFINE都要實行引用是低效的。參見緩存變量名。
例如，下面是爲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
陳舊的宏名
在Autoconf的第2版，大部分宏被重新命名以使用更加統一和具有描述性的命名方案。下面是被重新命名了的宏的原來名字，隨後給出了這些宏現在的名字。雖然爲了保持向後兼容，舊名字仍然能夠被autoconf程序所接受，舊名字都被看作過時的。關於新的命名方案，參見宏名。
AC_ALLOCA
AC_FUNC_ALLOCA
AC_ARG_ARRAY
因爲用途有限而被刪除了。
AC_CHAR_UNSIGNED
AC_C_CHAR_UNSIGNED
AC_CONST
AC_C_CONST
AC_CROSS_CHECK
AC_C_CROSS
AC_ERROR
AC_MSG_ERROR
AC_FIND_X
AC_PATH_X
AC_FIND_XTRA
AC_PATH_XTRA
AC_FUNC_CHECK
AC_CHECK_FUNC
AC_GCC_TRADITIONAL
AC_PROG_GCC_TRADITIONAL
AC_GETGROUPS_T
AC_TYPE_GETGROUPS
AC_GETLOADAVG
AC_FUNC_GETLOADAVG
AC_HAVE_FUNCS
AC_CHECK_FUNCS
AC_HAVE_HEADERS
AC_CHECK_HEADERS
AC_HAVE_POUNDBANG
AC_SYS_INTERPRETER (不同的調用慣例)
AC_HEADER_CHECK
AC_CHECK_HEADER 網管網www_bitscn_com
AC_HEADER_EGREP
AC_EGREP_HEADER
AC_INLINE
AC_C_INLINE
AC_LN_S
AC_PROG_LN_S
AC_LONG_DOUBLE
AC_C_LONG_DOUBLE
AC_LONG_FILE_NAMES
AC_SYS_LONG_FILE_NAMES
AC_MAJOR_HEADER
AC_HEADER_MAJOR
AC_MINUS_C_MINUS_O
AC_PROG_CC_C_O
AC_MMAP
AC_FUNC_MMAP
AC_MODE_T
AC_TYPE_MODE_T
AC_OFF_T
AC_TYPE_OFF_T
AC_PID_T
AC_TYPE_PID_T
AC_PREFIX
AC_PREFIX_PROGRAM
AC_PROGRAMS_CHECK
AC_CHECK_PROGS
AC_PROGRAMS_PATH
AC_PATH_PROGS
AC_PROGRAM_CHECK
AC_CHECK_PROG
AC_PROGRAM_EGREP
AC_EGREP_CPP
AC_PROGRAM_PATH
AC_PATH_PROG
AC_REMOTE_TAPE
因爲用途有限而被刪除了。
AC_RESTARTABLE_SYSCALLS
AC_SYS_RESTARTABLE_SYSCALLS
AC_RETSIGTYPE
AC_TYPE_SIGNAL
AC_RSH
因爲用途有限而被刪除了。
AC_SETVBUF_REVERSED
AC_FUNC_SETVBUF_REVERSED 網管u家u.bitscn@com
AC_SET_MAKE
AC_PROG_MAKE_SET
AC_SIZEOF_TYPE
AC_CHECK_SIZEOF
AC_SIZE_T
AC_TYPE_SIZE_T
AC_STAT_MACROS_BROKEN
AC_HEADER_STAT
AC_STDC_HEADERS
AC_HEADER_STDC
AC_STRCOLL
AC_FUNC_STRCOLL
AC_ST_BLKSIZE
AC_STRUCT_ST_BLKSIZE
AC_ST_BLOCKS
AC_STRUCT_ST_BLOCKS
AC_ST_RDEV
AC_STRUCT_ST_RDEV
AC_SYS_SIGLIST_DECLARED
AC_DECL_SYS_SIGLIST
AC_TEST_CPP
AC_TRY_CPP
AC_TEST_PROGRAM
AC_TRY_RUN
AC_TIMEZONE
AC_STRUCT_TIMEZONE
AC_TIME_WITH_SYS_TIME
AC_HEADER_TIME
AC_UID_T
AC_TYPE_UID_T
AC_UTIME_NULL
AC_FUNC_UTIME_NULL
AC_VFORK
AC_FUNC_VFORK
AC_VPRINTF
AC_FUNC_VPRINTF
AC_WAIT3
AC_FUNC_WAIT3
AC_WARN
AC_MSG_WARN
AC_WORDS_BIGENDIAN
AC_C_BIGENDIAN
AC_YYTEXT_POINTER
AC_DECL_YYTEXT
環境變量索引 網管網[url]www.bitscn.com[/url]
這是一個按照字母順序排序的，由Autoconf檢查的環境變量的列表。
Jump to: a - c - s
a
AC_MACRODIR, AC_MACRODIR, AC_MACRODIR, AC_MACRODIR, AC_MACRODIR, AC_MACRODIR
c
CONFIG_FILES
CONFIG_HEADERS
CONFIG_SHELL
CONFIG_SITE
CONFIG_STATUS
s
SIMPLE_BACKUP_SUFFIX
輸出變量索引
這是一個按照字母順序排序的，Autoconf將在它所創建的文件（通常是一個或更多`Makefile'）中進行替換的變量的列表。關於這些是如何實現的，請參見設定輸出變量。
Jump to: a - b - c - d - e - f - h - i - k - l - m - n - o - p - r - s - t - x - y
a
ALLOCA
AWK
b
bindir
build
build_alias
build_cpu
build_os
build_vendor
c
CC, CC, CC
CFLAGS, CFLAGS
configure_input
CPP
CPPFLAGS
CXX
CXXCPP
CXXFLAGS, CXXFLAGS
d
datadir
DEFS
e
exec_prefix
EXEEXT
網管下載dl.bitscn.com
在Autoconf的第2版，大部分宏被重新命名以使用更加統一和具有描述性的命名方案。下面是被重新命名了的宏的原來名字，隨後給出了這些宏現在的名字。雖然爲了保持向後兼容，舊名字仍然能夠被autoconf程序所接受，舊名字都被看作過時的。關於新的命名方案，參見宏名。
AC_ALLOCA
AC_FUNC_ALLOCA
AC_ARG_ARRAY
因爲用途有限而被刪除了。
AC_CHAR_UNSIGNED
AC_C_CHAR_UNSIGNED
AC_CONST
AC_C_CONST
AC_CROSS_CHECK
AC_C_CROSS
AC_ERROR
AC_MSG_ERROR
AC_FIND_X
AC_PATH_X
AC_FIND_XTRA
AC_PATH_XTRA
AC_FUNC_CHECK
AC_CHECK_FUNC
AC_GCC_TRADITIONAL
AC_PROG_GCC_TRADITIONAL
AC_GETGROUPS_T
AC_TYPE_GETGROUPS
AC_GETLOADAVG
AC_FUNC_GETLOADAVG
AC_HAVE_FUNCS
AC_CHECK_FUNCS
AC_HAVE_HEADERS
AC_CHECK_HEADERS
AC_HAVE_POUNDBANG
AC_SYS_INTERPRETER (不同的調用慣例)
AC_HEADER_CHECK
AC_CHECK_HEADER 網管網www_bitscn_com
AC_HEADER_EGREP
AC_EGREP_HEADER
AC_INLINE
AC_C_INLINE
AC_LN_S
AC_PROG_LN_S
AC_LONG_DOUBLE
AC_C_LONG_DOUBLE
AC_LONG_FILE_NAMES
AC_SYS_LONG_FILE_NAMES
AC_MAJOR_HEADER
AC_HEADER_MAJOR
AC_MINUS_C_MINUS_O
AC_PROG_CC_C_O
AC_MMAP
AC_FUNC_MMAP
AC_MODE_T
AC_TYPE_MODE_T
AC_OFF_T
AC_TYPE_OFF_T
AC_PID_T
AC_TYPE_PID_T
AC_PREFIX
AC_PREFIX_PROGRAM
AC_PROGRAMS_CHECK
AC_CHECK_PROGS
AC_PROGRAMS_PATH
AC_PATH_PROGS
AC_PROGRAM_CHECK
AC_CHECK_PROG
AC_PROGRAM_EGREP
AC_EGREP_CPP
AC_PROGRAM_PATH
AC_PATH_PROG
AC_REMOTE_TAPE
因爲用途有限而被刪除了。
AC_RESTARTABLE_SYSCALLS
AC_SYS_RESTARTABLE_SYSCALLS
AC_RETSIGTYPE
AC_TYPE_SIGNAL
AC_RSH
因爲用途有限而被刪除了。
AC_SETVBUF_REVERSED
AC_FUNC_SETVBUF_REVERSED 網管u家u.bitscn@com
AC_SET_MAKE
AC_PROG_MAKE_SET
AC_SIZEOF_TYPE
AC_CHECK_SIZEOF
AC_SIZE_T
AC_TYPE_SIZE_T
AC_STAT_MACROS_BROKEN
AC_HEADER_STAT
AC_STDC_HEADERS
AC_HEADER_STDC
AC_STRCOLL
AC_FUNC_STRCOLL
AC_ST_BLKSIZE
AC_STRUCT_ST_BLKSIZE
AC_ST_BLOCKS
AC_STRUCT_ST_BLOCKS
AC_ST_RDEV
AC_STRUCT_ST_RDEV
AC_SYS_SIGLIST_DECLARED
AC_DECL_SYS_SIGLIST
AC_TEST_CPP
AC_TRY_CPP
AC_TEST_PROGRAM
AC_TRY_RUN
AC_TIMEZONE
AC_STRUCT_TIMEZONE
AC_TIME_WITH_SYS_TIME
AC_HEADER_TIME
AC_UID_T
AC_TYPE_UID_T
AC_UTIME_NULL
AC_FUNC_UTIME_NULL
AC_VFORK
AC_FUNC_VFORK
AC_VPRINTF
AC_FUNC_VPRINTF
AC_WAIT3
AC_FUNC_WAIT3
AC_WARN
AC_MSG_WARN
AC_WORDS_BIGENDIAN
AC_C_BIGENDIAN
AC_YYTEXT_POINTER
AC_DECL_YYTEXT
環境變量索引 網管網[url]www.bitscn.com[/url]
這是一個按照字母順序排序的，由Autoconf檢查的環境變量的列表。
Jump to: a - c - s
a
AC_MACRODIR, AC_MACRODIR, AC_MACRODIR, AC_MACRODIR, AC_MACRODIR, AC_MACRODIR
c
CONFIG_FILES
CONFIG_HEADERS
CONFIG_SHELL
CONFIG_SITE
CONFIG_STATUS
s
SIMPLE_BACKUP_SUFFIX
輸出變量索引
這是一個按照字母順序排序的，Autoconf將在它所創建的文件（通常是一個或更多`Makefile'）中進行替換的變量的列表。關於這些是如何實現的，請參見設定輸出變量。
Jump to: a - b - c - d - e - f - h - i - k - l - m - n - o - p - r - s - t - x - y
a
ALLOCA
AWK
b
bindir
build
build_alias
build_cpu
build_os
build_vendor
c
CC, CC, CC
CFLAGS, CFLAGS
configure_input
CPP
CPPFLAGS
CXX
CXXCPP
CXXFLAGS, CXXFLAGS
d
datadir
DEFS
e
exec_prefix
EXEEXT
網管下載dl.bitscn.com
f
F77
FFLAGS, FFLAGS
FLIBS
h
host
host_alias
host_cpu
host_os
host_vendor
i
includedir
infodir
INSTALL
INSTALL_DATA
INSTALL_PROGRAM
INSTALL_SCRIPT
k
KMEM_GROUP
l
LDFLAGS
LEX
LEX_OUTPUT_ROOT
LEXLIB
libdir
libexecdir
LIBOBJS, LIBOBJS, LIBOBJS, LIBOBJS, LIBOBJS
LIBS, LIBS, LIBS
LN_S
localstatedir
m
mandir
n
NEED_SETGID
o
OBJEXT
oldincludedir
p
prefix
program_transform_name
r
RANLIB
s
sbindir
SET_MAKE
sharedstatedir
srcdir
subdirs
sysconfdir
t
target
target_alias
target_cpu
target_os
target_vendor
top_srcdir
x
X_CFLAGS
X_EXTRA_LIBS
X_LIBS
X_PRE_LIBS 中國網管論壇bbs.bitsCN.com
y
YACC
預處理器符號索引
這是一個按照字母順序排序的，由Autoconf宏定義的C預處理符號的列表。爲了與Autoconf協同工作，C源代碼應該在#if指令中使用這些名字。
Jump to: _ - c - d - f - g - h - i - l - m - n - o - p - r - s - t - u - v - w - y
_
__CHAR_UNSIGNED__
_ALL_SOURCE
_MINIX
_POSIX_1_SOURCE
_POSIX_SOURCE, _POSIX_SOURCE
_POSIX_VERSION
c
C_ALLOCA
CLOSEDIR_VOID
const
d
DGUX
DIRENT
f
F77_NO_MINUS_C_MINUS_O
g
GETGROUPS_T
GETLODAVG_PRIVILEGED
GETPGRP_VOID
gid_t
h
HAVE_ALLOCA_H
HAVE_CONFIG_H
HAVE_DIRENT_H
HAVE_DOPRNT
HAVE_function
HAVE_GETMNTENT
HAVE_header
HAVE_LONG_DOUBLE
HAVE_LONG_FILE_NAMES
HAVE_MMAP
HAVE_NDIR_H
HAVE_RESTARTABLE_SYSCALLS
HAVE_ST_BLKSIZE
HAVE_ST_BLOCKS
HAVE_ST_RDEV
網管聯盟bitsCN_com
F77
FFLAGS, FFLAGS
FLIBS
h
host
host_alias
host_cpu
host_os
host_vendor
i
includedir
infodir
INSTALL
INSTALL_DATA
INSTALL_PROGRAM
INSTALL_SCRIPT
k
KMEM_GROUP
l
LDFLAGS
LEX
LEX_OUTPUT_ROOT
LEXLIB
libdir
libexecdir
LIBOBJS, LIBOBJS, LIBOBJS, LIBOBJS, LIBOBJS
LIBS, LIBS, LIBS
LN_S
localstatedir
m
mandir
n
NEED_SETGID
o
OBJEXT
oldincludedir
p
prefix
program_transform_name
r
RANLIB
s
sbindir
SET_MAKE
sharedstatedir
srcdir
subdirs
sysconfdir
t
target
target_alias
target_cpu
target_os
target_vendor
top_srcdir
x
X_CFLAGS
X_EXTRA_LIBS
X_LIBS
X_PRE_LIBS 中國網管論壇bbs.bitsCN.com
y
YACC
預處理器符號索引
這是一個按照字母順序排序的，由Autoconf宏定義的C預處理符號的列表。爲了與Autoconf協同工作，C源代碼應該在#if指令中使用這些名字。
Jump to: _ - c - d - f - g - h - i - l - m - n - o - p - r - s - t - u - v - w - y
_
__CHAR_UNSIGNED__
_ALL_SOURCE
_MINIX
_POSIX_1_SOURCE
_POSIX_SOURCE, _POSIX_SOURCE
_POSIX_VERSION
c
C_ALLOCA
CLOSEDIR_VOID
const
d
DGUX
DIRENT
f
F77_NO_MINUS_C_MINUS_O
g
GETGROUPS_T
GETLODAVG_PRIVILEGED
GETPGRP_VOID
gid_t
h
HAVE_ALLOCA_H
HAVE_CONFIG_H
HAVE_DIRENT_H
HAVE_DOPRNT
HAVE_function
HAVE_GETMNTENT
HAVE_header
HAVE_LONG_DOUBLE
HAVE_LONG_FILE_NAMES
HAVE_MMAP
HAVE_NDIR_H
HAVE_RESTARTABLE_SYSCALLS
HAVE_ST_BLKSIZE
HAVE_ST_BLOCKS
HAVE_ST_RDEV
網管聯盟bitsCN_com
HAVE_STRCOLL
HAVE_STRFTIME
HAVE_STRINGIZE
HAVE_SYS_DIR_H
HAVE_SYS_NDIR_H
HAVE_SYS_WAIT_H
HAVE_TM_ZONE
HAVE_TZNAME
HAVE_UNISTD_H
HAVE_UTIME_NULL
HAVE_VFORK_H
HAVE_VPRINTF
HAVE_WAIT3
i
inline
INT_16_BITS
l
LONG_64_BITS
m
MAJOR_IN_MKDEV
MAJOR_IN_SYSMACROS
mode_t
n
NDIR
NEED_MEMORY_H
NEED_SETGID
NLIST_NAME_UNION
NLIST_STRUCT
NO_MINUS_C_MINUS_O
o
off_t
p
pid_t
r
RETSIGTYPE
s
SELECT_TYPE_ARG1
SELECT_TYPE_ARG234
SELECT_TYPE_ARG5
SETPGRP_VOID
SETVBUF_REVERSED
size_t
STDC_HEADERS
SVR4
SYS_SIGLIST_DECLARED
SYSDIR
SYSNDIR
t
TIME_WITH_SYS_TIME
TM_IN_SYS_TIME
u
uid_t
UMAX
UMAX4_3
USG
v 網管u家u.bitscn@com
vfork
VOID_CLOSEDIR
w
WORDS_BIGENDIAN
y
YYTEXT_POINTER
宏索引
這是按字母排序的Autoconf宏列表。爲了使列表易於使用，宏以沒有前綴`AC_'的形式列出。
Jump to: a - b - c - d - e - f - g - h - i - l - m - o - p - r - s - t - u - v - w - x - y
a
AIX
ALLOCA
ARG_ARRAY
ARG_ENABLE
ARG_PROGRAM
ARG_WITH
b
BEFORE
c
C_BIGENDIAN
C_CHAR_UNSIGNED
C_CONST
C_CROSS
C_INLINE
C_LONG_DOUBLE
C_STRINGIZE
CACHE_CHECK
CACHE_LOAD
CACHE_SAVE
CACHE_VAL
CANONICAL_HOST
CANONICAL_SYSTEM
CHAR_UNSIGNED
HAVE_STRFTIME
HAVE_STRINGIZE
HAVE_SYS_DIR_H
HAVE_SYS_NDIR_H
HAVE_SYS_WAIT_H
HAVE_TM_ZONE
HAVE_TZNAME
HAVE_UNISTD_H
HAVE_UTIME_NULL
HAVE_VFORK_H
HAVE_VPRINTF
HAVE_WAIT3
i
inline
INT_16_BITS
l
LONG_64_BITS
m
MAJOR_IN_MKDEV
MAJOR_IN_SYSMACROS
mode_t
n
NDIR
NEED_MEMORY_H
NEED_SETGID
NLIST_NAME_UNION
NLIST_STRUCT
NO_MINUS_C_MINUS_O
o
off_t
p
pid_t
r
RETSIGTYPE
s
SELECT_TYPE_ARG1
SELECT_TYPE_ARG234
SELECT_TYPE_ARG5
SETPGRP_VOID
SETVBUF_REVERSED
size_t
STDC_HEADERS
SVR4
SYS_SIGLIST_DECLARED
SYSDIR
SYSNDIR
t
TIME_WITH_SYS_TIME
TM_IN_SYS_TIME
u
uid_t
UMAX
UMAX4_3
USG
v 網管u家u.bitscn@com
vfork
VOID_CLOSEDIR
w
WORDS_BIGENDIAN
y
YYTEXT_POINTER
宏索引
這是按字母排序的Autoconf宏列表。爲了使列表易於使用，宏以沒有前綴`AC_'的形式列出。
Jump to: a - b - c - d - e - f - g - h - i - l - m - o - p - r - s - t - u - v - w - x - y
a
AIX
ALLOCA
ARG_ARRAY
ARG_ENABLE
ARG_PROGRAM
ARG_WITH
b
BEFORE
c
C_BIGENDIAN
C_CHAR_UNSIGNED
C_CONST
C_CROSS
C_INLINE
C_LONG_DOUBLE
C_STRINGIZE
CACHE_CHECK
CACHE_LOAD
CACHE_SAVE
CACHE_VAL
CANONICAL_HOST
CANONICAL_SYSTEM
CHAR_UNSIGNED