首页 > 工作总结

autoconf宏使用说明

更新时间:2023-12-09 21:33:28 阅读：评论：0

2023年12月9日发(作者：散文范文)

-

autoconf宏使用说明

AUTOCONF 常用宏

wh2010td@

AC_INIT (unique-file-in-source-dir)

寻找configure的输入文件

所有configure脚本在作任何其他事情之前都必须调用AC_INIT。此外唯一必须调用的宏是 AC_OUTPUT（参见创建输出文件）。

处理所有命令行参数并且寻找源代码目录。unique-file-in-source-dir是一些在包的源代码目录中文件； configure在目录中检查这些文件是否存在以确定该目录是否包含源代码。人们可能偶尔会用`--srcdir'给出错误的目录；这是一种安全性检查。详情请参见运行configure脚本。

AC_CONFIG_AUX_DIR (dir)

对于需要手工配置或者使用install程序的包来说，虽然在缺省源代码位置在大部分情况下看起来是正确的，包还是可能需要通过调用AC_CONFIG_AUX_DIR来告诉

configure到那里去寻找一些其他的shell脚本。

在目录dir中使用`install-sh'、`'、`'和 Cygnus

configure配置脚本。它们是配置中使用的辅助文件。dir既可以是绝对路径，也可以是相对于`srcdir'的相对路径。缺省值是在 `srcdir'或者 `srcdir/..'或者`srcdir/../..'中首先找到`install-sh' 的目录。不对其他文件进行检查，以便使AC_PROG_INSTALL不会自动地发布其他辅助文件。它还要检查`'，但因为有些 make程序包含了在没有`Makefile'的情况下从`'中创建`install'的规则，所以那个名字过时了。

AC_OUTPUT ([ [, extra-cmds [,

init-cmds]]])

创建输出文件

每个Autoconf生成的configure脚本必须以对AC_OUTPUT的调用结尾。它是一个创建作为配置结果的`Makefile'以及其他一些可能的文件的宏。此外唯一必须调用的宏是AC_INIT （参见寻找configure的输入文件）。

AC_PROG_MAKE_SET

如果你在子目录中运行make，你应该通过使用make变量MAKE来运行它。 make的大部分版本把MAKE设置成make的程序名以及它所需要的任何选项。（但许多版本并没有把在命令行中设定的变量的值包括进来，因此它们没有被自动地传递。）一些老版本的 make并不设定这个变量。以下的宏使你可以在这些版本上使用它。如果make预定义了变量MAKE，把输出变量SET_MAKE定义为空。否则，把 SET_MAKE定义成`MAKE=make'。为SET_MAKE调用AC_SUBST。

为了使用这个宏，在每个其他的、运行MAKE的目录中的`'添加一行：@SET_MAKE@

Makefiles中的替换

发布版本中每个包含了需要被编译或者被安装的文件的目录都应该含有一个文件`'， configure将利用它在那个目录中创建一个`Makefile'。

为了创建`Makefile'，configure进行一个简单的变量替换：用 configure 为`@variable@'选取的值，在`'中对它们进行替换。按照这种方式被替换到输出文件中的变量被称为输出变量。在 configure中，它们是普通的shell变量。为了让configure把特殊的变量替换到输出文件中，必须把那个变量的名字作为调用

AC_SUBST的参数。其他变量的任何`@variable@'都保持不变。关于使用AC_SUBST创建输出变量的详情，请参见设定输出变量。

使用configure脚本的软件应该发布文件`'，而不是`Makefile'；这样，用户就可以在编译它之前正确地为本地系统进行配置了。

关于应该把哪些东西放入`Makefile'的详情，请参见GNU编码标准中的`Makefile惯例'。

AH_TOP创建输出文件

在`'的末尾调用本宏一次。参数是一个以空格分隔的输出文件的列表；它可能为空。本宏通过从一个输入文件（缺省情况下名为`'）中复制，并替换输出变量的值以创建每个给出的`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/

lib/Makefile:templates/)

AC_OUTPUT(Makefile:templates/::templates/)

这样做可以使得你的文件名能够被MS-DOS接受，或者可以把模板文件（boilerplate）添加到文件的开头或者结尾。

如果你给出了extra-cmds，那么这些命令将被插入到`'中以便在`' 完成了其他的所有处理之后运行extra-cmds。如果给出了init-cmds，它们就被插入 extra-cmds之前，并且在configure中将对它们进行shell变量、命令和反斜线替换。你可以用 init-cmds把变量从configure中传递到extra-cmds。如果调用了 AC_OUTPUT_COMMANDS，在其中给出的命令将紧贴在由本宏给出的命令之前运行。

AC_DEFUN(macro-name, macro-body)

定义宏，宏的名字为name，具体实现为body。

Autoconf宏是用AC_DEFUN定义的，该宏与m4的内置define宏相似。除了定义一个宏，AC_DEFUN把某些用于限制宏调用顺序的代码添加到其中。（参见首要的宏）。

一个Autoconf宏像下面那样定义：AC_DEFUN(macro-name, [macro-body])

这里的方括号并不表示可选的文本：它们应当原样出现在宏定义中，以避免宏扩展问题（参见引用）。你可以使用`$1'、`$2'等等来访问传递给宏的任何参数。

为使用m4注释，使用m4内置的dnl；它使m4放弃本行中其后的所有文本。因为在调用AC_INIT之前，所有的输出都被取消，所以在`acsite.m4'和`aclocal.m4'中的宏定义之间不需要它。

关于编写m4宏的更完整的信息，参见GNU m4中的`如何定义新宏'。

宏名：所有Autoconf宏都以`AC_'起头以防止偶然地与其它文本发生冲突。所有它们用于内部目的的shell变量几乎全部是由小写字母组成的，并且以 `ac_'开头的名字。为了确保你的宏不会与现在的或者将来的Autoconf宏冲突，你应该给你自己的宏名和任何它们因为某些原因而需要使用的 shell变量添加前缀。它可能是你名字的开头字符，或者你的组织或软件包名称的缩写。

大部分Autoconf宏的名字服从一个表明特征检查的种类命名惯例。宏名由几个单词组成，由下划线分隔，可以是最常见的，也可以是最特殊的。它们的缓存变量名服从相同的惯例。（关于它们的详细信息，参见缓存变量名）。

`AC_'之后的第一个单词通常给出被测试特征的类别。下面是Autoconf为特殊测试宏使用的类别，它们是你很可能要编写的宏。它们的全小写形式还用于缓存变量。在可能的地方使用它们；如果不能，就发明一个你自己的类别。

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, :)

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, arch-libs [,

action-if-found [, action-if-not-found [,

other-libraries]]])

如果function还不可用，就寻找一个定义了function的库。这等同于首先不带库调用 AC_TRY_LINK_FUNC，而后为每个在arch-libs中列举的库调用AC_TRY_LINK_FUNC。

如果找到了函数，就运行action-if-found。否则运行action-if-not-found。

如果与库library的连接导致了未定义符号错误，而这些错误可以通过与附加的库进行连接来解决，就把这些库用空格分隔，并作为other- libraries参数给出：`-lXt

-lX11'。否则，本宏对function 是否存在的检测将总是失败，这是因为对测试程序的连接将总是因为含有未定义符号错误而失败。

AC_SEARCH_LIBS (function, arch-libs[,

action-if-found [, action-if-not-found]])

本宏等价于为每个在arch-libs中列举的库调用一次AC_TRY_LINK_FUNC。为找到的第一个含有 function的库，把`-llibrary'添加到LIBS中，并且执行 action-if-found。否则就执行action-if-not-found。

AC_MSG_CHECKING (feature-description)

告知用户configure正在检查特定的特征。本宏打印一条以`checking '开头，以`...' 结尾，而且不带新行的消息。它必须跟随一条对AC_MSG_RESULT的调用以打印检查的结果和新行。 feature-description应该是类似于 `whether the Fortran

compiler accepts C++ comments'或者`for c89'的东西。

如果运行configure给出了选项`--quiet'或者选项`--silent'，本宏什么也不打印。

AC_MSG_RESULT (result-description)

告知用户测试的结果。result-description几乎总是检查的缓存变量的值，典型的值是`yes'、 `no'或者文件名。本宏应该在AC_MSG_CHECKING之后调用，并且result-description 应该完成由AC_MSG_CHECKING所打印的消息。

如果运行configure给出了选项`--quiet'或者选项`--silent'，本宏什么也不打印。

AC_MSG_ERROR (error-description)

告知用户一条使configure不能完成的错误。本宏在标准错误输出中打印一条错误消息并且以非零状态退出 configure。error-description应该是类似于`invalid

value $HOME for $HOME'的东西。

AC_MSG_WARN (problem-description)

告知configure的使用者可能出现的问题。本宏在标准错误输出中打印消息；configure继续向后运行，所以调用AC_MSG_WARN的宏应该为它们所警告的情况提供一个缺省的（备份）行为。 problem-description应该是类似于`ln -s ems to make

hard links'的东西。

AC_ARG_WITH (package,help-string

[,action-if-given [,action-if-not-given]])

如果用户以选项`--with-package'或者`--without-package'调用

configure,就运行shell命令action-if-given。如果两个选项都没有给出,就运行shell命令 action-if-not-given。名字package给出了本程序应该与之协同工作的其它软件包。它应该仅仅由字母、数字和破折号（dashes）组成。

shell命令action-if-given可以通过shell变量withval得到选项的参数,该变量的值实际上就是把 shell变量with_package的值中的所有`-'字符替换为`_'而得的。如果你愿意,可以使用变量with_package。

参数help-string是对选项的描述,它看起来应该像：

--with-readline support fancy command line editing

如果需要给出更多的细节,help-string可能多于一行。只要确保`configure

--help'中的列的排列就可以了。不要在求助字符串中使用tab。你将需要用`['和`]'包围它以生成前导空格。

AC_WITH (package,action-if-given

[,action-if-not-given])

这是不支持求助字符串的AC_ARG_WITH的过时版本。

选择包选项

如果软件包含有可选的编译时（compile-time）特征,用户就可以在调用configure时使用命令行选项来指明是否编译它们。选项采用如下形式之一：

--enable-feature[=arg]

--disable-feature

这些选项允许用户选择可选的选项进行创建和安装。`--enable-feature'选项永远不要使特征的行为变得不同或者导致一个特征代替另一个特征。它们只应该导致程序的一部分被创建而另一部分不创建。

用户可以通过在特征名之后添加`='和参数来给出参数。给出参数`no'表示不能使用该特征。一个带有参数的特征看起来就像`--enable-debug=stabs'。如果没有给出参数,它的缺省值就是`yes'。`-- disable-feature'等价于

`--enable-feature=no'。

configure脚本并不对它们所不支持的`--enable-feature'选项发出警告。本特征允许顶层目录中的configure脚本配置一个包含多个包的源代码树。在包支持不同的选项的时候,不会因为给出了只有一部分包支持的选项而导致不必要的错误消息。一个不幸的副作用是选项的拼写错误就不能被检查出来了。迄今为止还没有处理该问题的更好办法。

对于每个可选的特征,`'都应该调用AC_ARG_ENABLE以检测configure 的用户是否要求把该特征包含进来。确定在缺省情况下,每个特征是否被包含进来,以及那些选项是合法的,是你的任务。

AC_ARG_ENABLE (feature,help-string

[,action-if-given [,action-if-not-given]])

如果用户以选项`--enable-feature'或者`--disable-feature'调用

configure,就运行shell命令action-if-given。如果两个选项都没有给出,就运行shell命令 action-if-not-given。名称feature表示可选的用户级功能。它应该仅仅由字母、数字和破折号（dashes）组成。

shell命令可以通过访问shell变量enableval来得到选项的参数,该变量的值实际上就是把shell变量 enable_feature的值中所有的`-'字符替换成`_'而得到的。如果你愿意,可以使用变量enable_feature。help- string参数类似于

AC_ARG_WITH中相应的参数（参见与外部软件一起工作）。

AC_ENABLE (feature,action-if-given

[,action-if-not-given])

这是不支持求助字符串的AC_ARG_ENABLE的过时版本。

AC_SUBST (variable)

设置输出变量

记录测试结果的一种方式是设置输出变量，该变量是shell变量，它的值将被替换到configure输出的文件中。下面的两个宏创建新的输出变量。关于总是可用的输出变量的列表，参见预定义输出变量。

从一个shell变量创建一个输出变量。让AC_OUTPUT把变量variable替换到输出文件中（通常是一个或多个 `Makefile'）。这意味着AC_OUTPUT将把输入文件中的`@variable@'实例替换成调用AC_OUTPUT时shell变量 variable的值。variable的值不能包含新行。

AC_SUBST_FILE (variable)

另一种从shell变量创建输出变量的方式。让AC_OUTPUT把由shell变量variable给出的文件名的文件的内容（不进行替换）插入到输出文件中。这意味着AC_OUTPUT将在输出文件中（比如`'）把输入文件中的`@variable@'实例替换为调用 AC_OUTPUT时shell变量variable的值指明的文件的内容。如果没有文件可以插入，就把变量设置成`/dev/null'。

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之中。如果找到了，就把变量

AC_CHECK_PROGS (variable, progs-to-check-for

[, value-if-not-found [, path]])

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 设置成找到的程序的完整路径。

获取规范的系统类型

下列的宏使得configure脚本可以获得系统类型。它们运行shell脚本以确定用户在命令行中没有给出的、它们需要的关于主机、目标和创建类型的所有值。它们运行对用户给出的任何别名进行规范化。如果你使用这些宏,你必须把这两个shell脚本与你的源代码一同发布。关于 AC_CONFIG_AUX_DIR的信息,你可以通过该宏设置configure查找这些脚本的目录,请参见创建输出文件。如果你没有使用这些宏中的任意一个,configure 就忽略任何传递给它的`--host'、`--target'和`--build'选项。

AC_CANONICAL_SYSTEM

检测系统类型并把输出变量设置成规范的系统类型。关于该宏设置变量的细节,参见系统类型变量。

AC_CANONICAL_HOST

只执行AC_CANONICAL_SYSTEM中关于主机类型功能的子集。对于不是编译工具链（compiler toolchain）一部分的程序,这就是所需要的全部功能。

AC_VALIDATE_CACHED_SYSTEM_TUPLE (cmd)

如果缓存文件与当前主机、目标和创建系统类型不一致,就执行cmd或者打印一个缺省的错误消息。系统类型变量

在调用了AC_CANONICAL_SYSTEM之后,下列输出变量包含了系统类型信息。在调用了AC_CANONICAL_HOST 之后,只设置了下列host变量。

build,host,target

规范系统名称

build_alias,host_alias,target_alias;如果使用了,就是用户指定的名称或者规范名称；build_cpu,build_vendor,build_os,host_cpu,host_vendor,host_os,target_cpu,target_vendor,target_os

为方便而提供的规范名称的独立部分。

使用系统类型

你将如何使用规范的系统类型？通常,你在`'中的一个或多个ca语句中使用它来选择系统特定的C文件。而后把那些使用基于系统名的文件名的文件连接到诸如`host.h'或`target.c'的普通的文件上。ca语句模型允许使用shell通配符对多种情况进行编组,就像下面的片断：

ca "$target" in

i386-*-mach* | i386-*-gnu*) obj_format=aout emulation=mach

bfd_gas=yes ;;

i960-*-bout) obj_format=bout ;;

esac

AC_DEFINE (variable [, value [, description]])

定义C预处理器变量variable。如果给出了value，就把variable设置成那个值（不加任何改变），否则的话就设置为1。value不应该含有新行，同时如果你没有使用AC_CONFIG_HEADER，它就不应该含有任何`#'字符，这是因为make将删除它们。为了使用shell变量（你需要使用该变量定义一个包含了 m4引用字符`['或者`]'的值），就使用AC_DEFINE_UNQUOTED。只有在你使用AC_CONFIG_HEADER的时候，

description才有用。在这种情况下，description被作为注释放置到生成的`'的宏定义之前；不必在 `acconfig.h'中提及该宏。下面的例子把 C预处理器变量EQUATION的值定义成常量字符串`"$a > $b"'：

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")

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 ( [,

action-if-found [, action-if-not-found]])

对于每个在以空格分隔的参数列表header-file出现的头文件，如果存在，就定义

HAVE_header-file（全部大写）。如果给出了action-if-found，它就是在找到一个头文件的时候执行的附加shell代码。你可以把`break'作为它的值以便在第一次匹配的时候跳出循环。如果给出了action-if-not-found，它就在找不到某个头文件的时候被执行。 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_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_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)

对特定函数的检查

库函数：以下的宏用于检测特定的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

# el # ifdef _AIX

#pragma alloca

# el

# ifndef alloca /* predefined by HP cc +Olibcalls */

char *alloca ();

# endif

#endif

AC_FUNC_CLOSEDIR_VOID

如果函数clodir不返回有意义的值，就定义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'，否则值就是`fal'。如果NEED_SETGID为`true'，本宏把KMEM_GROUP 设置成将拥有被安装的程序的组（group）的名字。

AC_FUNC_GETMNTENT

为Irix 4、PTX和Unixware在库`sun'、`q'和`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

确定函数lect的每个参数的正确类型，并且把这些类型分别定义成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

如果tpgrp不接受参数（POSIX.1版），就定义SETPGRP_VOID。否则，该函数就是一个把两个进程ID作为参数的BSD版本。本宏并不检查函数tpgrp是否存在；如果你需要检查该函数的存在性，就首先为tpgrp调用AC_CHECK_FUNC。

AC_FUNC_SETVBUF_REVERSED

如果函数tvbuf的第二个参数是缓冲区的类型并且第三个参数是缓冲区指针，而不是其他形式，就定义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 ( [,

action-if-found [, action-if-not-found]])

对于每个在以空格分隔的函数列表function中出现的函数，如果可用，就定义HAVE_function （全部大写）。如果给出了action-if-found，它就是在找到一个函数的时候执行的附加的shell代码。你可以给出 `break'以便在找到第一个匹配的时候跳出循环。如果给出了action-if-not-found，它就在找不到某个函数的时候执行。

AC_REPLACE_FUNCS ()

本宏的功能就类似于以将`function.o'添加到输出变量LIBOBJS的shell 代码为参数action-if-not-found，调用AC_CHECK_FUNCS。你可以通过用 `#ifndef

HAVE_function'包围你为函数提供的替代版本的原型来声明函数。如果系统含有该函数，它可能在一个你应该引入的头文件中进行声明，所以你不应该重新声明它，以避免声明冲突。

检验语法

为了检查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 (includes, function-body,

[action-if-found [, action-if-not-found]])

AC_TRY_LINK用于编译测试程序，以测试函数和全局变量。AC_CHECK_LIB还用本宏把被测试的库暂时地加入LIBS并试图连接一个小程序，从而对库进行检查（参见库文件）。根据当前语言（参见对语言的选择），创建一个测试程序以察看一个函数体为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]])

试图编译并且连接一个与function相连接的小程序。如果文件被成功地编译和连接了，就运行shell命令 action-if-found，否则就运行action-if-not-found。

AC_COMPILE_CHECK

function-body,

(echo-text, includes,

[, 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-fal

action-if-cross-compiling]]])

program是C程序的文本，将对该文本进行shell变量和反引用（backquote）替换。如果它被成功地编译和连接了并且在执行的时候返回的退出状态为0，就运行shell命令action-if-true。否则就运行shell命令action-if-fal；程序的退出状态[, 可以通过 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）为这些参数选择值（参见手工配置）。另一种方式是把测试缓存文件设置成目标系统的正确值（参见缓存结果）。