mirror of
https://github.com/eclipse-cdt/cdt
synced 2025-07-19 15:05:36 +02:00
11115 lines
499 KiB
XML
11115 lines
499 KiB
XML
<!-- This file automatically generated by ParseAutoconfTexinfo utility -->
|
|
<!-- cvs -d:pserver:anonymous@sources.redhat.com:/cvs/eclipse \ -->
|
|
<!-- co autotools/ParseTexinfo -->
|
|
<!DOCTYPE macros [
|
|
|
|
<!ELEMENT macros (macro)*>
|
|
|
|
<!ELEMENT macro (prototype*,synopsis)>
|
|
<!ATTLIST macro
|
|
id ID #REQUIRED
|
|
>
|
|
|
|
<!ELEMENT synopsis (#PCDATA)*>
|
|
|
|
<!ELEMENT prototype (parameter+)?>
|
|
|
|
<!ELEMENT parameter (#PCDATA)*>
|
|
<!ATTLIST parameter
|
|
content CDATA #REQUIRED
|
|
>
|
|
|
|
]>
|
|
|
|
<macros>
|
|
<macro id="AC_INIT">
|
|
<prototype>
|
|
<parameter content="package"/>
|
|
<parameter content="version"/>
|
|
<parameter content="[bug-report]"/>
|
|
<parameter content="@ [tarname]"/>
|
|
<parameter content="[url]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Process any command-line arguments and perform various
|
|
initializations and verifications.</P><P>
|
|
|
|
Set the name of the <VAR>package</VAR> and its
|
|
<VAR>version</VAR>. These are typically used in
|
|
<samp>--version</samp> support, including that of
|
|
<CODE>configure</CODE>. The optional argument
|
|
<VAR>bug-report</VAR> should be the email to which
|
|
users should send bug reports. The package
|
|
<VAR>tarname</VAR> differs from
|
|
<VAR>package</VAR>: the latter designates the full
|
|
package name (e.g., <samp>GNU Autoconf</samp>),
|
|
while the former is meant for distribution tar ball names (e.g.,
|
|
<samp>autoconf</samp>). It defaults to
|
|
<VAR>package</VAR> with <samp>GNU
|
|
</samp> stripped, lower-cased, and all characters other
|
|
than alphanumerics and underscores are changed to
|
|
<samp>-</samp>. If provided,
|
|
<VAR>url</VAR> should be the home page for the
|
|
package.</P><P>
|
|
|
|
The arguments of <CODE>AC_INIT</CODE> must be
|
|
static, i.e., there should not be any shell computation, quotes,
|
|
or newlines, but they can be computed by M4. This is because
|
|
the package information strings are expanded at M4 time into
|
|
several contexts, and must give the same text at shell time
|
|
whether used in single-quoted strings, double-quoted strings,
|
|
quoted here-documents, or unquoted here-documents. It is
|
|
permissible to use <CODE>m4_esyscmd</CODE> or
|
|
<CODE>m4_esyscmd_s</CODE> for computing a version
|
|
string that changes with every commit to a version control
|
|
system (in fact, Autoconf does just that, for all builds of the
|
|
development tree made between releases).</P><P>
|
|
|
|
The following M4 macros (e.g.,
|
|
<CODE>AC_PACKAGE_NAME</CODE>), output variables
|
|
(e.g., <CODE>PACKAGE_NAME</CODE>), and preprocessor
|
|
symbols (e.g., <CODE>PACKAGE_NAME</CODE>), are
|
|
defined by <CODE>AC_INIT</CODE>:</P><P>
|
|
|
|
<DL> <DT><CODE>AC_PACKAGE_NAME</CODE>,
|
|
<CODE>PACKAGE_NAME</CODE> <DD> Exactly
|
|
<VAR>package</VAR>.</P><P>
|
|
|
|
<DT><CODE>AC_PACKAGE_TARNAME</CODE>,
|
|
<CODE>PACKAGE_TARNAME</CODE> <DD> Exactly
|
|
<VAR>tarname</VAR>, possibly generated from
|
|
<VAR>package</VAR>.</P><P>
|
|
|
|
<DT><CODE>AC_PACKAGE_VERSION</CODE>,
|
|
<CODE>PACKAGE_VERSION</CODE> <DD> Exactly
|
|
<VAR>version</VAR>.</P><P>
|
|
|
|
<DT><CODE>AC_PACKAGE_STRING</CODE>,
|
|
<CODE>PACKAGE_STRING</CODE> <DD> Exactly
|
|
<samp><VAR>package</VAR>
|
|
<VAR>version</VAR></samp>.</P><P>
|
|
|
|
<DT><CODE>AC_PACKAGE_BUGREPORT</CODE>,
|
|
<CODE>PACKAGE_BUGREPORT</CODE> <DD> Exactly
|
|
<VAR>bug-report</VAR>, if one was provided.
|
|
Typically an email address, or URL to a bug management web page.</P><P>
|
|
|
|
<DT><CODE>AC_PACKAGE_URL</CODE>,
|
|
<CODE>PACKAGE_URL</CODE> <DD> Exactly
|
|
<VAR>url</VAR>, if one was provided. If
|
|
<VAR>url</VAR> was empty, but
|
|
<VAR>package</VAR> begins with <samp>GNU
|
|
</samp>, then this defaults to
|
|
<samp>http://@/www.gnu.org/@/software/@/<VAR>tarname</VAR>/</samp>,
|
|
otherwise, no URL is assumed. </DL>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PREREQ">
|
|
<prototype>
|
|
<parameter content="version"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Ensure that a recent enough version of Autoconf is being used.
|
|
If the version of Autoconf being used to create
|
|
<CODE>configure</CODE> is earlier than
|
|
<VAR>version</VAR>, print an error message to the
|
|
standard error output and exit with failure (exit status is 63).
|
|
For example:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PREREQ([VERSION])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro may be used before <CODE>AC_INIT</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_AUTOCONF_VERSION">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62. It identifies the
|
|
version of Autoconf that is currently parsing the input file, in
|
|
a format suitable for
|
|
<CODE>m4_version_compare</CODE>
|
|
(m4_version_compare); in other words, for this release of
|
|
Autoconf, its value is <samp>VERSION</samp>. One
|
|
potential use of this macro is for writing conditional fallbacks
|
|
based on when a feature was added to Autoconf, rather than using
|
|
<CODE>AC_PREREQ</CODE> to require the newer version
|
|
of Autoconf. However, remember that the Autoconf philosophy
|
|
favors feature checks over version checks.</P><P>
|
|
|
|
You should not expand this macro directly; use
|
|
<samp>m4_defn([AC_AUTOCONF_VERSION])</samp> instead.
|
|
This is because some users might have a beta version of
|
|
Autoconf installed, with arbitrary letters included in its
|
|
version string. This means it is possible for the version
|
|
string to contain the name of a defined macro, such that
|
|
expanding <CODE>AC_AUTOCONF_VERSION</CODE> would
|
|
trigger the expansion of that macro during rescanning, and
|
|
change the version string to be different than what you intended
|
|
to check.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_COPYRIGHT">
|
|
<prototype>
|
|
<parameter content="copyright-notice"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Notice State that, in addition to the Free Software
|
|
Foundation's copyright on the Autoconf macros, parts of your
|
|
<CODE>configure</CODE> are covered by the
|
|
<VAR>copyright-notice</VAR>.</P><P>
|
|
|
|
The <VAR>copyright-notice</VAR> shows up in both the
|
|
head of <CODE>configure</CODE> and in
|
|
<samp>configure --version</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_REVISION">
|
|
<prototype>
|
|
<parameter content="revision-info"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Copy revision stamp <VAR>revision-info</VAR> into
|
|
the <CODE>configure</CODE> script, with any dollar
|
|
signs or double-quotes removed. This macro lets you put a
|
|
revision stamp from <TT>configure.ac</TT> into
|
|
<CODE>configure</CODE> without RCS or CVS changing
|
|
it when you check in <CODE>configure</CODE>. That
|
|
way, you can determine easily which revision of
|
|
<TT>configure.ac</TT> a particular
|
|
<CODE>configure</CODE> corresponds to.</P><P>
|
|
|
|
For example, this line in <TT>configure.ac</TT>:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_REVISION([$Revision: 1.30 $])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
produces this in <CODE>configure</CODE>:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #!/bin/sh # From configure.ac
|
|
Revision: 1.30 </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_SRCDIR">
|
|
<prototype>
|
|
<parameter content="unique-file-in-source-dir"/>
|
|
</prototype>
|
|
<synopsis>
|
|
<VAR>unique-file-in-source-dir</VAR> is some file
|
|
that is in the package's source directory;
|
|
<CODE>configure</CODE> checks for this file's
|
|
existence to make sure that the directory that it is told
|
|
contains the source code in fact does. Occasionally people
|
|
accidentally specify the wrong directory with
|
|
<samp>--srcdir</samp>; this is a safety check. ,
|
|
for more information.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_AUX_DIR">
|
|
<prototype>
|
|
<parameter content="dir"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Use the auxiliary build tools (e.g.,
|
|
<TT>install-sh</TT>,
|
|
<TT>config.sub</TT>,
|
|
<TT>config.guess</TT>, Cygnus
|
|
<CODE>configure</CODE>, Automake and Libtool
|
|
scripts, etc.)@: that are in directory
|
|
<VAR>dir</VAR>. These are auxiliary files used in
|
|
configuration. <VAR>dir</VAR> can be either
|
|
absolute or relative to
|
|
<TT><VAR>srcdir</VAR></TT>. The default
|
|
is <TT><VAR>srcdir</VAR></TT> or
|
|
<TT><VAR>srcdir</VAR>/..</TT> or
|
|
<TT><VAR>srcdir</VAR>/../..</TT>,
|
|
whichever is the first that contains
|
|
<TT>install-sh</TT>. The other files are not
|
|
checked for, so that using
|
|
<CODE>AC_PROG_INSTALL</CODE> does not automatically
|
|
require distributing the other auxiliary files. It checks for
|
|
<TT>install.sh</TT> also, but that name is obsolete
|
|
because some <CODE>make</CODE> have a rule that
|
|
creates <TT>install</TT> from it if there is no
|
|
makefile.</P><P>
|
|
|
|
The auxiliary directory is commonly named
|
|
<TT>build-aux</TT>. If you need portability to DOS
|
|
variants, do not name the auxiliary directory
|
|
<TT>aux</TT>. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_REQUIRE_AUX_FILE">
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Declares that <VAR>file</VAR> is expected in the
|
|
directory defined above. In Autoconf proper, this macro does
|
|
nothing: its sole purpose is to be traced by third-party tools
|
|
to produce a list of expected auxiliary files. For instance it
|
|
is called by macros like
|
|
<CODE>AC_PROG_INSTALL</CODE> (Particular Programs)
|
|
or <CODE>AC_CANONICAL_BUILD</CODE> (Canonicalizing)
|
|
to register the auxiliary files they need.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_MACRO_DIR">
|
|
<prototype>
|
|
<parameter content="dir"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Specify <VAR>dir</VAR> as the location of
|
|
additional local Autoconf macros. This macro is intended for use
|
|
by future versions of commands like
|
|
<CODE>autoreconf</CODE> that trace macro calls. It
|
|
should be called directly from <TT>configure.ac</TT>
|
|
so that tools that install macros for
|
|
<CODE>aclocal</CODE> can find the macros'
|
|
declarations.</P><P>
|
|
|
|
Note that if you use <CODE>aclocal</CODE> from
|
|
Automake to generate <TT>aclocal.m4</TT>, you must
|
|
also set <CODE>ACLOCAL_AMFLAGS = -I
|
|
<VAR>dir</VAR></CODE> in your top-level
|
|
<TT>Makefile.am</TT>. Due to a limitation in the
|
|
Autoconf implementation of <CODE>autoreconf</CODE>,
|
|
these include directives currently must be set on a single line
|
|
in <TT>Makefile.am</TT>, without any
|
|
backslash-newlines.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_OUTPUT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Generate <TT>config.status</TT> and launch it.
|
|
Call this macro once, at the end of
|
|
<TT>configure.ac</TT>.</P><P>
|
|
|
|
<TT>config.status</TT> performs all the
|
|
configuration actions: all the output files (see Configuration
|
|
Files, macro <CODE>AC_CONFIG_FILES</CODE>), header
|
|
files (see Configuration Headers, macro
|
|
<CODE>AC_CONFIG_HEADERS</CODE>), commands (see
|
|
Configuration Commands, macro
|
|
<CODE>AC_CONFIG_COMMANDS</CODE>), links (see
|
|
Configuration Links, macro
|
|
<CODE>AC_CONFIG_LINKS</CODE>), subdirectories to
|
|
configure (see Subdirectories, macro
|
|
<CODE>AC_CONFIG_SUBDIRS</CODE>) are honored.</P><P>
|
|
|
|
The location of your <CODE>AC_OUTPUT</CODE>
|
|
invocation is the exact point where configuration actions are
|
|
taken: any code afterwards is executed by
|
|
<CODE>configure</CODE> once
|
|
<CODE>config.status</CODE> was run. If you want to
|
|
bind actions to <CODE>config.status</CODE> itself
|
|
(independently of whether <CODE>configure</CODE> is
|
|
being run), see Configuration Commands, , Running Arbitrary
|
|
Configuration Commands.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_MAKE_SET">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the Make command, <CODE>$MAKE</CODE> if set or
|
|
else <samp>make</samp>, predefines
|
|
<CODE>$(MAKE)</CODE>, define output variable
|
|
<CODE>SET_MAKE</CODE> to be empty. Otherwise, define
|
|
<CODE>SET_MAKE</CODE> to a macro definition that
|
|
sets <CODE>$(MAKE)</CODE>, such as
|
|
<samp>MAKE=make</samp>. Calls
|
|
<CODE>AC_SUBST</CODE> for
|
|
<CODE>SET_MAKE</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_FILES">
|
|
<prototype>
|
|
<parameter content="file..."/>
|
|
<parameter content="[cmds]"/>
|
|
<parameter content="[init-cmds]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Make <CODE>AC_OUTPUT</CODE> create each
|
|
<TT><VAR>file</VAR></TT> by copying an
|
|
input file (by default
|
|
<TT><VAR>file</VAR>.in</TT>),
|
|
substituting the output variable values. This macro is one of
|
|
the instantiating macros; see Configuration Actions. , for more
|
|
information on using output variables. , for more information
|
|
on creating them. This macro creates the directory that the
|
|
file is in if it doesn't exist. Usually, makefiles are created
|
|
this way, but other files, such as
|
|
<TT>.gdbinit</TT>, can be specified as well.</P><P>
|
|
|
|
Typical calls to <CODE>AC_CONFIG_FILES</CODE> look
|
|
like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CONFIG_FILES([Makefile
|
|
src/Makefile man/Makefile X/Imakefile])
|
|
AC_CONFIG_FILES([autoconf], [chmod +x autoconf])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You can override an input file name by appending to
|
|
<VAR>file</VAR> a colon-separated list of input
|
|
files. Examples:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
AC_CONFIG_FILES([Makefile:boiler/top.mk:boiler/bot.mk]
|
|
[lib/Makefile:boiler/lib.mk])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Doing this allows you to keep your file names acceptable to DOS
|
|
variants, or to prepend and/or append boilerplate to the file.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_HEADERS">
|
|
<prototype>
|
|
<parameter content="header ..."/>
|
|
<parameter content="[cmds]"/>
|
|
<parameter content="[init-cmds]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is one of the instantiating macros; see
|
|
Configuration Actions. Make <CODE>AC_OUTPUT</CODE>
|
|
create the file(s) in the blank-or-newline-separated list
|
|
<VAR>header</VAR> containing C preprocessor
|
|
<CODE>#define</CODE> statements, and replace
|
|
<samp>@@DEFS@@</samp> in generated files with
|
|
<samp>-DHAVE_CONFIG_H</samp> instead of the value of
|
|
<CODE>DEFS</CODE>. The usual name for
|
|
<VAR>header</VAR> is <TT>config.h</TT>.</P><P>
|
|
|
|
If <VAR>header</VAR> already exists and its contents
|
|
are identical to what <CODE>AC_OUTPUT</CODE> would
|
|
put in it, it is left alone. Doing this allows making some
|
|
changes in the configuration without needlessly causing object
|
|
files that depend on the header file to be recompiled.</P><P>
|
|
|
|
Usually the input file is named
|
|
<TT><VAR>header</VAR>.in</TT>; however,
|
|
you can override the input file name by appending to
|
|
<VAR>header</VAR> a colon-separated list of input
|
|
files. For example, you might need to make the input file name
|
|
acceptable to DOS variants:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
AC_CONFIG_HEADERS([config.h:config.hin])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AH_HEADER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is defined as the name of the first declared config
|
|
header and undefined if no config headers have been declared up
|
|
to this point. A third-party macro may, for example, require use
|
|
of a config header without invoking AC_CONFIG_HEADERS twice,
|
|
like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CONFIG_COMMANDS_PRE(
|
|
[m4_ifndef([AH_HEADER], [AC_CONFIG_HEADERS([config.h])])])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AH_TEMPLATE">
|
|
<prototype>
|
|
<parameter content="key"/>
|
|
<parameter content="description"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Tell <CODE>autoheader</CODE> to generate a template
|
|
for <VAR>key</VAR>. This macro generates standard
|
|
templates just like <CODE>AC_DEFINE</CODE> when a
|
|
<VAR>description</VAR> is given.</P><P>
|
|
|
|
For example:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AH_TEMPLATE([CRAY_STACKSEG_END],
|
|
[Define to one of _getb67, GETB67, getb67
|
|
for Cray-2 and Cray-YMP systems. This function is
|
|
required for alloca.c support on those systems.])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
generates the following template, with the description properly
|
|
justified.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> /* Define to one of _getb67,
|
|
GETB67, getb67 for Cray-2 and Cray-YMP systems. This
|
|
function is required for alloca.c support on those systems.
|
|
*/ #undef CRAY_STACKSEG_END
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AH_VERBATIM">
|
|
<prototype>
|
|
<parameter content="key"/>
|
|
<parameter content="template"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Tell <CODE>autoheader</CODE> to include the
|
|
<VAR>template</VAR> as-is in the header template
|
|
file. This <VAR>template</VAR> is associated with
|
|
the <VAR>key</VAR>, which is used to sort all the
|
|
different templates and guarantee their uniqueness. It should
|
|
be a symbol that can be defined via
|
|
<CODE>AC_DEFINE</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AH_TOP">
|
|
<prototype>
|
|
<parameter content="text"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Include <VAR>text</VAR> at the top of the header
|
|
template file.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AH_BOTTOM">
|
|
<prototype>
|
|
<parameter content="text"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Include <VAR>text</VAR> at the bottom of the header
|
|
template file.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_COMMANDS">
|
|
<prototype>
|
|
<parameter content="tag..."/>
|
|
<parameter content="[cmds]"/>
|
|
<parameter content="[init-cmds]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Specify additional shell commands to run at the end of
|
|
<TT>config.status</TT>, and shell commands to
|
|
initialize any variables from
|
|
<CODE>configure</CODE>. Associate the commands with
|
|
<VAR>tag</VAR>. Since typically the
|
|
<VAR>cmds</VAR> create a file,
|
|
<VAR>tag</VAR> should naturally be the name of that
|
|
file. If needed, the directory hosting
|
|
<VAR>tag</VAR> is created. This macro is one of the
|
|
instantiating macros; see Configuration Actions.</P><P>
|
|
|
|
Here is an unrealistic example:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> fubar=42
|
|
AC_CONFIG_COMMANDS([fubar], [echo this is
|
|
extra $fubar, and so on.], [fubar=$fubar])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here is a better one:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CONFIG_COMMANDS([timestamp],
|
|
[date >timestamp])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_COMMANDS_PRE">
|
|
<prototype>
|
|
<parameter content="cmds"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Execute the <VAR>cmds</VAR> right before creating
|
|
<TT>config.status</TT>.</P><P>
|
|
|
|
This macro presents the last opportunity to call
|
|
<CODE>AC_SUBST</CODE>,
|
|
<CODE>AC_DEFINE</CODE>, or
|
|
<CODE>AC_CONFIG_<VAR>ITEMS</VAR></CODE>
|
|
macros.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_COMMANDS_POST">
|
|
<prototype>
|
|
<parameter content="cmds"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Execute the <VAR>cmds</VAR> right after creating
|
|
<TT>config.status</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_LINKS">
|
|
<prototype>
|
|
<parameter content="dest:source..."/>
|
|
<parameter content="[cmds]"/>
|
|
<parameter content="@ [init-cmds]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Make <CODE>AC_OUTPUT</CODE> link each of the
|
|
existing files <VAR>source</VAR> to the
|
|
corresponding link name <VAR>dest</VAR>. Makes a
|
|
symbolic link if possible, otherwise a hard link if possible,
|
|
otherwise a copy. The <VAR>dest</VAR> and
|
|
<VAR>source</VAR> names should be relative to the
|
|
top level source or build directory. This macro is one of the
|
|
instantiating macros; see Configuration Actions.</P><P>
|
|
|
|
For example, this call:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
AC_CONFIG_LINKS([host.h:config/$machine.h
|
|
object.h:config/$obj_format.h])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
creates in the current directory <TT>host.h</TT> as
|
|
a link to
|
|
<TT><VAR>srcdir</VAR>/config/$machine.h</TT>,
|
|
and <TT>object.h</TT> as a link to
|
|
<TT><VAR>srcdir</VAR>/config/$obj_format.h</TT>.</P><P>
|
|
|
|
The tempting value <samp>.</samp> for
|
|
<VAR>dest</VAR> is invalid: it makes it impossible
|
|
for <samp>config.status</samp> to guess the links to
|
|
establish.</P><P>
|
|
|
|
One can then run:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> ./config.status host.h object.h
|
|
</pre></td></tr></table> to create the
|
|
links.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_SUBDIRS">
|
|
<prototype>
|
|
<parameter content="dir ..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Make <CODE>AC_OUTPUT</CODE> run
|
|
<CODE>configure</CODE> in each subdirectory
|
|
<VAR>dir</VAR> in the given
|
|
blank-or-newline-separated list. Each
|
|
<VAR>dir</VAR> should be a literal, i.e., please do
|
|
not use:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> if test "x$package_foo_enabled" =
|
|
xyes; then my_subdirs="$my_subdirs foo" fi
|
|
AC_CONFIG_SUBDIRS([$my_subdirs])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
because this prevents <samp>./configure
|
|
--help=recursive</samp> from displaying the options of the
|
|
package <CODE>foo</CODE>. Instead, you should
|
|
write:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> if test "x$package_foo_enabled" =
|
|
xyes; then AC_CONFIG_SUBDIRS([foo]) fi
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If a given <VAR>dir</VAR> is not found at
|
|
<CODE>configure</CODE> run time, a warning is
|
|
reported; if the subdirectory is optional, write:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> if test -d "$srcdir/foo"; then
|
|
AC_CONFIG_SUBDIRS([foo]) fi
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If a given <VAR>dir</VAR> contains
|
|
<CODE>configure.gnu</CODE>, it is run instead of
|
|
<CODE>configure</CODE>. This is for packages that
|
|
might use a non-Autoconf script
|
|
<CODE>Configure</CODE>, which can't be called
|
|
through a wrapper <CODE>configure</CODE> since it
|
|
would be the same file on case-insensitive file systems.
|
|
Likewise, if a <VAR>dir</VAR> contains
|
|
<TT>configure.in</TT> but no
|
|
<CODE>configure</CODE>, the Cygnus
|
|
<CODE>configure</CODE> script found by
|
|
<CODE>AC_CONFIG_AUX_DIR</CODE> is used.</P><P>
|
|
|
|
The subdirectory <CODE>configure</CODE> scripts are
|
|
given the same command line options that were given to this
|
|
<CODE>configure</CODE> script, with minor changes if
|
|
needed, which include:</P><P>
|
|
|
|
<UL> <LI> adjusting a relative name for the cache
|
|
file;</P><P>
|
|
|
|
<LI> adjusting a relative name for the source directory;</P><P>
|
|
|
|
<LI> propagating the current value of
|
|
<CODE>$prefix</CODE>, including if it was defaulted,
|
|
and if the default values of the top level and of the
|
|
subdirectory <TT>configure</TT> differ. </UL></P><P>
|
|
|
|
This macro also sets the output variable
|
|
<CODE>subdirs</CODE> to the list of directories
|
|
<samp><VAR>dir</VAR>
|
|
<small>...</small></samp>. Make rules can use
|
|
this variable to determine which subdirectories to recurse into.</P><P>
|
|
|
|
This macro may be called multiple times.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PREFIX_DEFAULT">
|
|
<prototype>
|
|
<parameter content="prefix"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Set the default installation prefix to
|
|
<VAR>prefix</VAR> instead of
|
|
<TT>/usr/local</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PREFIX_PROGRAM">
|
|
<prototype>
|
|
<parameter content="program"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If the user did not specify an installation prefix (using the
|
|
<samp>--prefix</samp> option), guess a value for it
|
|
by looking for <VAR>program</VAR> in PATH, the way
|
|
the shell does. If <VAR>program</VAR> is found, set
|
|
the prefix to the parent of the directory containing
|
|
<VAR>program</VAR>, else default the prefix as
|
|
described above (<TT>/usr/local</TT> or
|
|
<CODE>AC_PREFIX_DEFAULT</CODE>). For example, if
|
|
<VAR>program</VAR> is <CODE>gcc</CODE>
|
|
and the PATH contains
|
|
<TT>/usr/local/gnu/bin/gcc</TT>, set the prefix to
|
|
<TT>/usr/local/gnu</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_INCLUDES_DEFAULT">
|
|
<prototype>
|
|
<parameter content="[include-directives]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand to <VAR>include-directives</VAR> if defined,
|
|
otherwise to:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group #include <stdio.h>
|
|
#ifdef HAVE_SYS_TYPES_H # include <sys/types.h> #endif
|
|
#ifdef HAVE_SYS_STAT_H # include <sys/stat.h> #endif
|
|
#ifdef STDC_HEADERS # include <stdlib.h> # include
|
|
<stddef.h> #else # ifdef HAVE_STDLIB_H # include
|
|
<stdlib.h> # endif #endif #ifdef HAVE_STRING_H # if
|
|
!defined STDC_HEADERS && defined HAVE_MEMORY_H #
|
|
include <memory.h> # endif # include <string.h>
|
|
#endif #ifdef HAVE_STRINGS_H # include <strings.h> #endif
|
|
#ifdef HAVE_INTTYPES_H # include <inttypes.h> #endif
|
|
#ifdef HAVE_STDINT_H # include <stdint.h> #endif #ifdef
|
|
HAVE_UNISTD_H # include <unistd.h> #endif @end group
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If the default includes are used, then check for the presence of
|
|
these headers and their compatibility, i.e., you don't need to
|
|
run <CODE>AC_HEADER_STDC</CODE>, nor check for
|
|
<TT>stdlib.h</TT> etc.</P><P>
|
|
|
|
These headers are checked for in the same order as they are
|
|
included. For instance, on some systems
|
|
<TT>string.h</TT> and <TT>strings.h</TT>
|
|
both exist, but conflict. Then
|
|
<CODE>HAVE_STRING_H</CODE> is defined, not
|
|
<CODE>HAVE_STRINGS_H</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_AWK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check for <CODE>gawk</CODE>,
|
|
<CODE>mawk</CODE>, <CODE>nawk</CODE>,
|
|
and <CODE>awk</CODE>, in that order, and set output
|
|
variable <CODE>AWK</CODE> to the first one that is
|
|
found. It tries <CODE>gawk</CODE> first because that
|
|
is reported to be the best implementation. The result can be
|
|
overridden by setting the variable <CODE>AWK</CODE>
|
|
or the cache variable <CODE>ac_cv_prog_AWK</CODE>.</P><P>
|
|
|
|
Using this macro is sufficient to avoid the pitfalls of
|
|
traditional <CODE>awk</CODE> (awk, , Limitations of
|
|
Usual Tools).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_GREP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Look for the best available <CODE>grep</CODE> or
|
|
<CODE>ggrep</CODE> that accepts the longest input
|
|
lines possible, and that supports multiple
|
|
<samp>-e</samp> options. Set the output variable
|
|
<CODE>GREP</CODE> to whatever is chosen. , for more
|
|
information about portability problems with the
|
|
<CODE>grep</CODE> command family. The result can be
|
|
overridden by setting the <CODE>GREP</CODE> variable
|
|
and is cached in the <CODE>ac_cv_path_GREP</CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_EGREP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check whether <CODE>$GREP -E</CODE> works, or
|
|
else look for the best available <CODE>egrep</CODE>
|
|
or <CODE>gegrep</CODE> that accepts the longest
|
|
input lines possible. Set the output variable
|
|
<CODE>EGREP</CODE> to whatever is chosen. The
|
|
result can be overridden by setting the
|
|
<CODE>EGREP</CODE> variable and is cached in the
|
|
<CODE>ac_cv_path_EGREP</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_FGREP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check whether <CODE>$GREP -F</CODE> works, or
|
|
else look for the best available <CODE>fgrep</CODE>
|
|
or <CODE>gfgrep</CODE> that accepts the longest
|
|
input lines possible. Set the output variable
|
|
<CODE>FGREP</CODE> to whatever is chosen. The
|
|
result can be overridden by setting the
|
|
<CODE>FGREP</CODE> variable and is cached in the
|
|
<CODE>ac_cv_path_FGREP</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_INSTALL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>INSTALL</CODE> to
|
|
the name of a BSD-compatible <CODE>install</CODE>
|
|
program, if one is found in the current PATH. Otherwise, set
|
|
<CODE>INSTALL</CODE> to
|
|
<samp><VAR>dir</VAR>/install-sh
|
|
-c</samp>, checking the directories specified to
|
|
<CODE>AC_CONFIG_AUX_DIR</CODE> (or its default
|
|
directories) to determine <VAR>dir</VAR> (Output).
|
|
Also set the variables <CODE>INSTALL_PROGRAM</CODE>
|
|
and <CODE>INSTALL_SCRIPT</CODE> to
|
|
<samp>$INSTALL@</samp> and
|
|
<CODE>INSTALL_DATA</CODE> to
|
|
<samp>$INSTALL@</samp> -m 644.</P><P>
|
|
|
|
<samp>@@INSTALL@@</samp> is special, as its value
|
|
may vary for different configuration files.</P><P>
|
|
|
|
This macro screens out various instances of
|
|
<CODE>install</CODE> known not to work. It prefers
|
|
to find a C program rather than a shell script, for speed.
|
|
Instead of <TT>install-sh</TT>, it can also use
|
|
<TT>install.sh</TT>, but that name is obsolete
|
|
because some <CODE>make</CODE> programs have a rule
|
|
that creates <TT>install</TT> from it if there is no
|
|
makefile. Further, this macro requires
|
|
<CODE>install</CODE> to be able to install multiple
|
|
files into a target directory in a single invocation.</P><P>
|
|
|
|
Autoconf comes with a copy of <TT>install-sh</TT>
|
|
that you can use. If you use
|
|
<CODE>AC_PROG_INSTALL</CODE>, you must include
|
|
either <TT>install-sh</TT> or
|
|
<TT>install.sh</TT> in your distribution; otherwise
|
|
<CODE>configure</CODE> produces an error message
|
|
saying it can't find them---even if the system you're on has a
|
|
good <CODE>install</CODE> program. This check is a
|
|
safety measure to prevent you from accidentally leaving that
|
|
file out, which would prevent your package from installing on
|
|
systems that don't have a BSD-compatible
|
|
<CODE>install</CODE> program.</P><P>
|
|
|
|
If you need to use your own installation program because it has
|
|
features not found in standard <CODE>install</CODE>
|
|
programs, there is no reason to use
|
|
<CODE>AC_PROG_INSTALL</CODE>; just put the file name
|
|
of your program into your <TT>Makefile.in</TT>
|
|
files.</P><P>
|
|
|
|
The result of the test can be overridden by setting the variable
|
|
<CODE>INSTALL</CODE> or the cache variable
|
|
<CODE>ac_cv_path_install</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_MKDIR_P">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>MKDIR_P</CODE> to a
|
|
program that ensures that for each argument, a directory named
|
|
by this argument exists, creating it and its parent directories
|
|
if needed, and without race conditions when two instances of the
|
|
program attempt to make the same directory at nearly the same
|
|
time.</P><P>
|
|
|
|
This macro uses the <samp>mkdir -p</samp> command if
|
|
possible. Otherwise, it falls back on invoking
|
|
<CODE>install-sh</CODE> with the
|
|
<samp>-d</samp> option, so your package should
|
|
contain <TT>install-sh</TT> as described under
|
|
<CODE>AC_PROG_INSTALL</CODE>. An
|
|
<TT>install-sh</TT> file that predates Autoconf 2.60
|
|
or Automake 1.10 is vulnerable to race conditions, so if you
|
|
want to support parallel installs from different packages into
|
|
the same directory you need to make sure you have an up-to-date
|
|
<TT>install-sh</TT>. In particular, be careful
|
|
about using <samp>autoreconf -if</samp> if your
|
|
Automake predates Automake 1.10.</P><P>
|
|
|
|
This macro is related to the <CODE>AS_MKDIR_P</CODE>
|
|
macro (Programming in M4sh), but it sets an output variable
|
|
intended for use in other files, whereas
|
|
<CODE>AS_MKDIR_P</CODE> is intended for use in
|
|
scripts like <CODE>configure</CODE>. Also,
|
|
<CODE>AS_MKDIR_P</CODE> does not accept options, but
|
|
<CODE>MKDIR_P</CODE> supports the
|
|
<samp>-m</samp> option, e.g., a makefile might
|
|
invoke <CODE>$(MKDIR_P) -m 0 dir</CODE> to create an
|
|
inaccessible directory, and conversely a makefile should use
|
|
<CODE>$(MKDIR_P) -- $(FOO)</CODE> if
|
|
<VAR>FOO</VAR> might yield a value that begins with
|
|
<samp>-</samp>. Finally,
|
|
<CODE>AS_MKDIR_P</CODE> does not check for race
|
|
condition vulnerability, whereas
|
|
<CODE>AC_PROG_MKDIR_P</CODE> does.</P><P>
|
|
|
|
<samp>@@MKDIR_P@@</samp> is special, as its value
|
|
may vary for different configuration files.</P><P>
|
|
|
|
The result of the test can be overridden by setting the variable
|
|
<CODE>MKDIR_P</CODE> or the cache variable
|
|
<CODE>ac_cv_path_mkdir</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_LEX">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>flex</CODE> is found, set output
|
|
variable <CODE>LEX</CODE> to
|
|
<samp>flex</samp> and
|
|
<CODE>LEXLIB</CODE> to
|
|
<samp>-lfl</samp>, if that library is in a standard
|
|
place. Otherwise set <CODE>LEX</CODE> to
|
|
<samp>lex</samp> and <CODE>LEXLIB</CODE>
|
|
to <samp>-ll</samp>, if found. If neither variant
|
|
is available, set <CODE>LEX</CODE> to
|
|
<samp>:</samp>; for packages that ship the generated
|
|
<TT>file.yy.c</TT> alongside the source
|
|
<TT>file.l</TT>, this default allows users without a
|
|
lexer generator to still build the package even if the timestamp
|
|
for <TT>file.l</TT> is inadvertantly changed.</P><P>
|
|
|
|
Define <CODE>YYTEXT_POINTER</CODE> if
|
|
<CODE>yytext</CODE> defaults to <samp>char
|
|
*</samp> instead of to <samp>char []</samp>.
|
|
Also set output variable
|
|
<CODE>LEX_OUTPUT_ROOT</CODE> to the base of the file
|
|
name that the lexer generates; usually
|
|
<TT>lex.yy</TT>, but sometimes something else.
|
|
These results vary according to whether
|
|
<CODE>lex</CODE> or <CODE>flex</CODE> is
|
|
being used.</P><P>
|
|
|
|
You are encouraged to use Flex in your sources, since it is both
|
|
more pleasant to use than plain Lex and the C source it produces
|
|
is portable. In order to ensure portability, however, you must
|
|
either provide a function <CODE>yywrap</CODE> or, if
|
|
you don't use it (e.g., your scanner has no
|
|
<samp>#include</samp>-like feature), simply include
|
|
a <samp>%noyywrap</samp> statement in the scanner's
|
|
source. Once this done, the scanner is portable (unless
|
|
<EM>you</EM> felt free to use nonportable
|
|
constructs) and does not depend on any library. In this case,
|
|
and in this case only, it is suggested that you use this
|
|
Autoconf snippet:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PROG_LEX if test "x$LEX" !=
|
|
xflex; then LEX="$SHELL $missing_dir/missing flex"
|
|
AC_SUBST([LEX_OUTPUT_ROOT], [lex.yy]) AC_SUBST([LEXLIB], [''])
|
|
fi </pre></td></tr></table></P><P>
|
|
|
|
The shell script <CODE>missing</CODE> can be found
|
|
in the Automake distribution.</P><P>
|
|
|
|
Remember that the user may have supplied an alternate location
|
|
in LEX, so if Flex is required, it is better to check that the
|
|
user provided something sufficient by parsing the output of
|
|
<samp>$LEX --version</samp> than by simply relying
|
|
on <CODE>test "x$LEX" = xflex</CODE>.</P><P>
|
|
|
|
To ensure backward compatibility, Automake's
|
|
<CODE>AM_PROG_LEX</CODE> invokes (indirectly) this
|
|
macro twice, which causes an annoying but benign
|
|
``<CODE>AC_PROG_LEX</CODE> invoked multiple times''
|
|
warning. Future versions of Automake will fix this issue;
|
|
meanwhile, just ignore this message.</P><P>
|
|
|
|
As part of running the test, this macro may delete any file in
|
|
the configuration directory named <TT>lex.yy.c</TT>
|
|
or <TT>lexyy.c</TT>.</P><P>
|
|
|
|
The result of this test can be influenced by setting the
|
|
variable <CODE>LEX</CODE> or the cache variable
|
|
<CODE>ac_cv_prog_LEX</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_LN_S">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <samp>ln -s</samp> works on the current file
|
|
system (the operating system and file system support symbolic
|
|
links), set the output variable <CODE>LN_S</CODE> to
|
|
<samp>ln -s</samp>; otherwise, if
|
|
<samp>ln</samp> works, set
|
|
<CODE>LN_S</CODE> to <samp>ln</samp>,
|
|
and otherwise set it to <samp>cp -p</samp>.</P><P>
|
|
|
|
If you make a link in a directory other than the current
|
|
directory, its meaning depends on whether
|
|
<samp>ln</samp> or <samp>ln -s</samp> is
|
|
used. To safely create links using
|
|
<samp>$(LN_S)</samp>, either find out which form is
|
|
used and adjust the arguments, or always invoke
|
|
<CODE>ln</CODE> in the directory where the link is
|
|
to be created.</P><P>
|
|
|
|
In other words, it does not work to do:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> $(LN_S) foo /x/bar
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Instead, do:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> (cd /x && $(LN_S) foo bar)
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_RANLIB">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>RANLIB</CODE> to
|
|
<samp>ranlib</samp> if
|
|
<CODE>ranlib</CODE> is found, and otherwise to
|
|
<samp>:</samp> (do nothing).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_SED">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>SED</CODE> to a Sed
|
|
implementation that conforms to Posix and does not have
|
|
arbitrary length limits. Report an error if no acceptable Sed
|
|
is found. , for more information about portability problems
|
|
with Sed.</P><P>
|
|
|
|
The result of this test can be overridden by setting the
|
|
<CODE>SED</CODE> variable and is cached in the
|
|
<CODE>ac_cv_path_SED</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_YACC">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>bison</CODE> is found, set output
|
|
variable <CODE>YACC</CODE> to <samp>bison
|
|
-y</samp>. Otherwise, if <CODE>byacc</CODE>
|
|
is found, set <CODE>YACC</CODE> to
|
|
<samp>byacc</samp>. Otherwise set
|
|
<CODE>YACC</CODE> to <samp>yacc</samp>.
|
|
The result of this test can be influenced by setting the
|
|
variable <CODE>YACC</CODE> or the cache variable
|
|
<CODE>ac_cv_prog_YACC</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_PROG">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
<VAR>value-if-found</VAR>, value-if-not-found,
|
|
path, $PATH, @ reject) Check whether program
|
|
<VAR>prog-to-check-for</VAR> exists in
|
|
<VAR>path</VAR>. If it is found, set
|
|
<VAR>variable</VAR> to
|
|
<VAR>value-if-found</VAR>, otherwise to
|
|
<VAR>value-if-not-found</VAR>, if given. Always
|
|
pass over <VAR>reject</VAR> (an absolute file name)
|
|
even if it is the first found in the search path; in that case,
|
|
set <VAR>variable</VAR> using the absolute file name
|
|
of the <VAR>prog-to-check-for</VAR> found that is
|
|
not <VAR>reject</VAR>. If
|
|
<VAR>variable</VAR> was already set, do nothing.
|
|
Calls <CODE>AC_SUBST</CODE> for
|
|
<VAR>variable</VAR>. The result of this test can be
|
|
overridden by setting the <VAR>variable</VAR>
|
|
variable or the cache variable
|
|
<CODE>ac_cv_prog_<VAR>variable</VAR></CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_PROGS">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="progs-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Check for each program in the blank-separated list
|
|
<VAR>progs-to-check-for</VAR> existing in the
|
|
<VAR>path</VAR>. If one is found, set
|
|
<VAR>variable</VAR> to the name of that program.
|
|
Otherwise, continue checking the next program in the list. If
|
|
none of the programs in the list are found, set
|
|
<VAR>variable</VAR> to
|
|
<VAR>value-if-not-found</VAR>; if
|
|
<VAR>value-if-not-found</VAR> is not specified, the
|
|
value of <VAR>variable</VAR> is not changed. Calls
|
|
<CODE>AC_SUBST</CODE> for
|
|
<VAR>variable</VAR>. The result of this test can be
|
|
overridden by setting the <VAR>variable</VAR>
|
|
variable or the cache variable
|
|
<CODE>ac_cv_prog_<VAR>variable</VAR></CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_TARGET_TOOL">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="prog-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_PROG</CODE>, but first looks
|
|
for <VAR>prog-to-check-for</VAR> with a prefix of
|
|
the target type as determined by
|
|
<CODE>AC_CANONICAL_TARGET</CODE>, followed by a dash
|
|
(Canonicalizing). If the tool cannot be found with a prefix, and
|
|
if the build and target types are equal, then it is also
|
|
searched for without a prefix.</P><P>
|
|
|
|
As noted in Specifying Target Triplets, the target is rarely
|
|
specified, because most of the time it is the same as the host:
|
|
it is the type of system for which any compiler tool in the
|
|
package produces code. What this macro looks for is, for
|
|
example, <EM>a tool (assembler, linker, etc.)</EM>@:
|
|
that the compiler driver (<CODE>gcc</CODE> for the
|
|
GNU C Compiler) uses to produce objects, archives or
|
|
executables.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_TOOL">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="prog-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_PROG</CODE>, but first looks
|
|
for <VAR>prog-to-check-for</VAR> with a prefix of
|
|
the host type as specified by <samp>--host</samp>,
|
|
followed by a dash. For example, if the user runs
|
|
<samp>configure --build=x86_64-gnu
|
|
--host=i386-gnu</samp>, then this call:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_TOOL([RANLIB], [ranlib],
|
|
[:]) </pre></td></tr></table> sets
|
|
<CODE>RANLIB</CODE> to
|
|
<TT>i386-gnu-ranlib</TT> if that program exists in
|
|
<VAR>path</VAR>, or otherwise to
|
|
<samp>ranlib</samp> if that program exists in
|
|
<VAR>path</VAR>, or to <samp>:</samp> if
|
|
neither program exists.</P><P>
|
|
|
|
When cross-compiling, this macro will issue a warning if no
|
|
program prefixed with the host type could be found. For more
|
|
information, see Specifying Target Triplets.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_TARGET_TOOLS">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="progs-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_TARGET_TOOL</CODE>, each of the
|
|
tools in the list <VAR>progs-to-check-for</VAR> are
|
|
checked with a prefix of the target type as determined by
|
|
<CODE>AC_CANONICAL_TARGET</CODE>, followed by a dash
|
|
(Canonicalizing). If none of the tools can be found with a
|
|
prefix, and if the build and target types are equal, then the
|
|
first one without a prefix is used. If a tool is found, set
|
|
<VAR>variable</VAR> to the name of that program. If
|
|
none of the tools in the list are found, set
|
|
<VAR>variable</VAR> to
|
|
<VAR>value-if-not-found</VAR>; if
|
|
<VAR>value-if-not-found</VAR> is not specified, the
|
|
value of <VAR>variable</VAR> is not changed. Calls
|
|
<CODE>AC_SUBST</CODE> for
|
|
<VAR>variable</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_TOOLS">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="progs-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_TOOL</CODE>, each of the tools
|
|
in the list <VAR>progs-to-check-for</VAR> are
|
|
checked with a prefix of the host type as determined by
|
|
<CODE>AC_CANONICAL_HOST</CODE>, followed by a dash
|
|
(Canonicalizing). If none of the tools can be found with a
|
|
prefix, then the first one without a prefix is used. If a tool
|
|
is found, set <VAR>variable</VAR> to the name of
|
|
that program. If none of the tools in the list are found, set
|
|
<VAR>variable</VAR> to
|
|
<VAR>value-if-not-found</VAR>; if
|
|
<VAR>value-if-not-found</VAR> is not specified, the
|
|
value of <VAR>variable</VAR> is not changed. Calls
|
|
<CODE>AC_SUBST</CODE> for
|
|
<VAR>variable</VAR>.</P><P>
|
|
|
|
When cross-compiling, this macro will issue a warning if no
|
|
program prefixed with the host type could be found. For more
|
|
information, see Specifying Target Triplets.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PATH_PROG">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="prog-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_PROG</CODE>, but set
|
|
<VAR>variable</VAR> to the absolute name of
|
|
<VAR>prog-to-check-for</VAR> if found. The result
|
|
of this test can be overridden by setting the
|
|
<VAR>variable</VAR> variable. A positive result of
|
|
this test is cached in the
|
|
<CODE>ac_cv_path_<VAR>variable</VAR></CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PATH_PROGS">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="progs-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_PROGS</CODE>, but if any of
|
|
<VAR>progs-to-check-for</VAR> are found, set
|
|
<VAR>variable</VAR> to the absolute name of the
|
|
program found. The result of this test can be overridden by
|
|
setting the <VAR>variable</VAR> variable. A
|
|
positive result of this test is cached in the
|
|
<CODE>ac_cv_path_<VAR>variable</VAR></CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PATH_PROGS_FEATURE_CHECK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
<VAR>progs-to-check-for</VAR>,
|
|
<VAR>feature-test</VAR>, @ action-if-not-found,
|
|
path, $PATH) This macro was introduced in Autoconf 2.62. If
|
|
<VAR>variable</VAR> is not empty, then set the cache
|
|
variable
|
|
<CODE>ac_cv_path_<VAR>variable</VAR></CODE>
|
|
to its value. Otherwise, check for each program in the
|
|
blank-separated list <VAR>progs-to-check-for</VAR>
|
|
existing in <VAR>path</VAR>. For each program
|
|
found, execute <VAR>feature-test</VAR> with
|
|
<CODE>ac_path_<VAR>variable</VAR></CODE>
|
|
set to the absolute name of the candidate program. If no
|
|
invocation of <VAR>feature-test</VAR> sets the shell
|
|
variable
|
|
<CODE>ac_cv_path_<VAR>variable</VAR></CODE>,
|
|
then <VAR>action-if-not-found</VAR> is executed.
|
|
<VAR>feature-test</VAR> will be run even when
|
|
<CODE>ac_cv_path_<VAR>variable</VAR></CODE>
|
|
is set, to provide the ability to choose a better candidate
|
|
found later in <VAR>path</VAR>; to accept the
|
|
current setting and bypass all futher checks,
|
|
<VAR>feature-test</VAR> can execute
|
|
<CODE>ac_path_<VAR>variable</VAR>_found=:</CODE>.</P><P>
|
|
|
|
Note that this macro has some subtle differences from
|
|
<CODE>AC_CHECK_PROGS</CODE>. It is designed to be
|
|
run inside <CODE>AC_CACHE_VAL</CODE>, therefore, it
|
|
should have no side effects. In particular,
|
|
<VAR>variable</VAR> is not set to the final value of
|
|
<CODE>ac_cv_path_<VAR>variable</VAR></CODE>,
|
|
nor is <CODE>AC_SUBST</CODE> automatically run.
|
|
Also, on failure, any action can be performed, whereas
|
|
<CODE>AC_CHECK_PROGS</CODE> only performs
|
|
<CODE><VAR>variable</VAR>=<VAR>value-if-not-found</VAR></CODE>.</P><P>
|
|
|
|
Here is an example, similar to what Autoconf uses in its own
|
|
configure script. It will search for an implementation of
|
|
<CODE>m4</CODE> that supports the
|
|
<CODE>indir</CODE> builtin, even if it goes by the
|
|
name <CODE>gm4</CODE> or is not the first
|
|
implementation on PATH.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CACHE_CHECK([for m4 that
|
|
supports indir], [ac_cv_path_M4],
|
|
[AC_PATH_PROGS_FEATURE_CHECK([M4], [m4 gm4], [[m4out=`echo
|
|
'changequote([,])indir([divnum])' | $ac_path_M4` test
|
|
"x$m4out" = x0 \ && ac_cv_path_M4=$ac_path_M4
|
|
ac_path_M4_found=:]], [AC_MSG_ERROR([could not find m4 that
|
|
supports indir])])]) AC_SUBST([M4], [$ac_cv_path_M4])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PATH_TARGET_TOOL">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="prog-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_TARGET_TOOL</CODE>, but set
|
|
<VAR>variable</VAR> to the absolute name of the
|
|
program if it is found.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PATH_TOOL">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="prog-to-check-for"/>
|
|
<parameter content="@ [value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_TOOL</CODE>, but set
|
|
<VAR>variable</VAR> to the absolute name of the
|
|
program if it is found.</P><P>
|
|
|
|
When cross-compiling, this macro will issue a warning if no
|
|
program prefixed with the host type could be found. For more
|
|
information, see Specifying Target Triplets.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_FILE">
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Check whether file <VAR>file</VAR> exists on the
|
|
native system. If it is found, execute
|
|
<VAR>action-if-found</VAR>, otherwise do
|
|
<VAR>action-if-not-found</VAR>, if given. The
|
|
result of this test is cached in the
|
|
<CODE>ac_cv_file_<VAR>file</VAR></CODE>
|
|
variable, with characters not suitable for a variable name
|
|
mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_FILES">
|
|
<prototype>
|
|
<parameter content="files"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Executes <CODE>AC_CHECK_FILE</CODE> once for each
|
|
file listed in <VAR>files</VAR>. Additionally,
|
|
defines
|
|
<samp>HAVE_<VAR>file</VAR></samp>
|
|
(Standard Symbols) for each file found. The results of each
|
|
test are cached in the
|
|
<CODE>ac_cv_file_<VAR>file</VAR></CODE>
|
|
variable, with characters not suitable for a variable name
|
|
mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_LIB">
|
|
<prototype>
|
|
<parameter content="library"/>
|
|
<parameter content="function"/>
|
|
<parameter content="@ [action-if-found]"/>
|
|
<parameter content="[action-if-not-found]"/>
|
|
<parameter content="[other-libraries]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Test whether the library <VAR>library</VAR> is
|
|
available by trying to link a test program that calls function
|
|
<VAR>function</VAR> with the library.
|
|
<VAR>function</VAR> should be a function provided by
|
|
the library. Use the base name of the library; e.g., to check
|
|
for <samp>-lmp</samp>, use
|
|
<samp>mp</samp> as the
|
|
<VAR>library</VAR> argument.</P><P>
|
|
|
|
<VAR>action-if-found</VAR> is a list of shell
|
|
commands to run if the link with the library succeeds;
|
|
<VAR>action-if-not-found</VAR> is a list of shell
|
|
commands to run if the link fails. If
|
|
<VAR>action-if-found</VAR> is not specified, the
|
|
default action prepends
|
|
<samp>-l<VAR>library</VAR></samp> to
|
|
<CODE>LIBS</CODE> and defines
|
|
<samp>HAVE_LIB<VAR>library</VAR></samp>
|
|
(in all capitals). This macro is intended to support building
|
|
<CODE>LIBS</CODE> in a right-to-left
|
|
(least-dependent to most-dependent) fashion such that library
|
|
dependencies are satisfied as a natural side effect of
|
|
consecutive tests. Linkers are sensitive to library ordering so
|
|
the order in which <CODE>LIBS</CODE> is generated is
|
|
important to reliable detection of libraries.</P><P>
|
|
|
|
If linking with <VAR>library</VAR> results in
|
|
unresolved symbols that would be resolved by linking with
|
|
additional libraries, give those libraries as the
|
|
<VAR>other-libraries</VAR> argument, separated by
|
|
spaces: e.g., <samp>-lXt -lX11</samp>. Otherwise,
|
|
this macro may fail to detect that
|
|
<VAR>library</VAR> is present, because linking the
|
|
test program can fail with unresolved symbols. The
|
|
<VAR>other-libraries</VAR> argument should be
|
|
limited to cases where it is desirable to test for one library
|
|
in the presence of another that is not already in
|
|
<CODE>LIBS</CODE>.</P><P>
|
|
|
|
<CODE>AC_CHECK_LIB</CODE> requires some care in
|
|
usage, and should be avoided in some common cases. Many
|
|
standard functions like <CODE>gethostbyname</CODE>
|
|
appear in the standard C library on some hosts, and in special
|
|
libraries like <CODE>nsl</CODE> on other hosts. On
|
|
some hosts the special libraries contain variant implementations
|
|
that you may not want to use. These days it is normally better
|
|
to use <CODE>AC_SEARCH_LIBS([gethostbyname],
|
|
[nsl])</CODE> instead of <CODE>AC_CHECK_LIB([nsl],
|
|
[gethostbyname])</CODE>.</P><P>
|
|
|
|
The result of this test is cached in the
|
|
<CODE>ac_cv_lib_<VAR>library</VAR>_<VAR>function</VAR></CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SEARCH_LIBS">
|
|
<prototype>
|
|
<parameter content="function"/>
|
|
<parameter content="search-libs"/>
|
|
<parameter content="@ [action-if-found]"/>
|
|
<parameter content="[action-if-not-found]"/>
|
|
<parameter content="[other-libraries]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Search for a library defining <VAR>function</VAR>
|
|
if it's not already available. This equates to calling
|
|
<samp>AC_LINK_IFELSE([AC_LANG_CALL([],
|
|
[<VAR>function</VAR>])])</samp> first with no
|
|
libraries, then for each library listed in
|
|
<VAR>search-libs</VAR>.</P><P>
|
|
|
|
Prepend
|
|
<samp>-l<VAR>library</VAR></samp> to
|
|
<CODE>LIBS</CODE> for the first library found to
|
|
contain <VAR>function</VAR>, and run
|
|
<VAR>action-if-found</VAR>. If the function is not
|
|
found, run <VAR>action-if-not-found</VAR>.</P><P>
|
|
|
|
If linking with <VAR>library</VAR> results in
|
|
unresolved symbols that would be resolved by linking with
|
|
additional libraries, give those libraries as the
|
|
<VAR>other-libraries</VAR> argument, separated by
|
|
spaces: e.g., <samp>-lXt -lX11</samp>. Otherwise,
|
|
this macro fails to detect that <VAR>function</VAR>
|
|
is present, because linking the test program always fails with
|
|
unresolved symbols.</P><P>
|
|
|
|
The result of this test is cached in the
|
|
<CODE>ac_cv_search_<VAR>function</VAR></CODE>
|
|
variable as <samp>none required</samp> if
|
|
<VAR>function</VAR> is already available, as
|
|
<samp>no</samp> if no library containing
|
|
<VAR>function</VAR> was found, otherwise as the
|
|
<samp>-l<VAR>library</VAR></samp> option
|
|
that needs to be prepended to <CODE>LIBS</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_ALLOCA">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
alloca.h Check how to get <CODE>alloca</CODE>.
|
|
Tries to get a builtin version by checking for
|
|
<TT>alloca.h</TT> or the predefined C preprocessor
|
|
macros <CODE>__GNUC__</CODE> and
|
|
<CODE>_AIX</CODE>. If this macro finds
|
|
<TT>alloca.h</TT>, it defines
|
|
<CODE>HAVE_ALLOCA_H</CODE>.</P><P>
|
|
|
|
If those attempts fail, it looks for the function in the
|
|
standard C library. If any of those methods succeed, it defines
|
|
<CODE>HAVE_ALLOCA</CODE>. Otherwise, it sets the
|
|
output variable <CODE>ALLOCA</CODE> to
|
|
<samp>$LIBOBJDIR@</samp>alloca.o and defines
|
|
<CODE>C_ALLOCA</CODE> (so programs can periodically
|
|
call <samp>alloca (0)</samp> to garbage collect).
|
|
This variable is separate from <CODE>LIBOBJS</CODE>
|
|
so multiple programs can share the value of
|
|
<CODE>ALLOCA</CODE> without needing to create an
|
|
actual library, in case only some of them use the code in
|
|
<CODE>LIBOBJS</CODE>. The
|
|
<samp>$LIBOBJDIR@</samp> prefix serves the same
|
|
purpose as in <CODE>LIBOBJS</CODE> (AC_LIBOBJ vs
|
|
LIBOBJS).</P><P>
|
|
|
|
This macro does not try to get <CODE>alloca</CODE>
|
|
from the System V R3 <TT>libPW</TT> or the System V
|
|
R4 <TT>libucb</TT> because those libraries contain
|
|
some incompatible functions that cause trouble. Some versions
|
|
do not even contain <CODE>alloca</CODE> or contain a
|
|
buggy version. If you still want to use their
|
|
<CODE>alloca</CODE>, use <CODE>ar</CODE>
|
|
to extract <TT>alloca.o</TT> from them instead of
|
|
compiling <TT>alloca.c</TT>.</P><P>
|
|
|
|
Source files that use <CODE>alloca</CODE> should
|
|
start with a piece of code like the following, to declare it
|
|
properly.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group #ifdef STDC_HEADERS #
|
|
include <stdlib.h> # include <stddef.h> #else #
|
|
ifdef HAVE_STDLIB_H # include <stdlib.h> # endif #endif
|
|
#ifdef HAVE_ALLOCA_H # include <alloca.h> #elif defined
|
|
__GNUC__ # define alloca __builtin_alloca #elif defined _AIX #
|
|
define alloca __alloca #elif defined _MSC_VER # include
|
|
<malloc.h> # define alloca _alloca #else # ifndef
|
|
HAVE_ALLOCA # ifdef __cplusplus extern "C" # endif void
|
|
*alloca (size_t); # endif #endif @end group
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_CHOWN">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>chown</CODE> function is available
|
|
and works (in particular, it should accept
|
|
<samp>-1</samp> for <CODE>uid</CODE> and
|
|
<CODE>gid</CODE>), define
|
|
<CODE>HAVE_CHOWN</CODE>. The result of this macro
|
|
is cached in the <CODE>ac_cv_func_chown_works</CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_CLOSEDIR_VOID">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>closedir</CODE> function does not
|
|
return a meaningful value, define
|
|
<CODE>CLOSEDIR_VOID</CODE>. Otherwise, callers
|
|
ought to check its return value for an error indicator.</P><P>
|
|
|
|
Currently this test is implemented by running a test program.
|
|
When cross compiling the pessimistic assumption that
|
|
<CODE>closedir</CODE> does not return a meaningful
|
|
value is made.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_closedir_void</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as <CODE>closedir</CODE>
|
|
returns a meaningful value on current systems. New programs
|
|
need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_ERROR_AT_LINE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>error_at_line</CODE> function is not
|
|
found, require an <CODE>AC_LIBOBJ</CODE> replacement
|
|
of <samp>error</samp>.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_lib_error_at_line</CODE> variable.</P><P>
|
|
|
|
The <CODE>AC_FUNC_ERROR_AT_LINE</CODE> macro is
|
|
obsolescent. New programs should use Gnulib's
|
|
<CODE>error</CODE> module. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_FNMATCH">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>fnmatch</CODE> function conforms to
|
|
Posix, define <CODE>HAVE_FNMATCH</CODE>. Detect
|
|
common implementation bugs, for example, the bugs in Solaris
|
|
2.4.</P><P>
|
|
|
|
Unlike the other specific <CODE>AC_FUNC</CODE>
|
|
macros, <CODE>AC_FUNC_FNMATCH</CODE> does not
|
|
replace a broken/missing <CODE>fnmatch</CODE>. This
|
|
is for historical reasons. See
|
|
<CODE>AC_REPLACE_FNMATCH</CODE> below.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_fnmatch_works</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent. New programs should use Gnulib's
|
|
<CODE>fnmatch-posix</CODE> module. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_FNMATCH_GNU">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Behave like <CODE>AC_REPLACE_FNMATCH</CODE>
|
|
(<EM>replace</EM>) but also test whether
|
|
<CODE>fnmatch</CODE> supports GNU extensions.
|
|
Detect common implementation bugs, for example, the bugs in the
|
|
GNU C Library 2.1.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_fnmatch_gnu</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent. New programs should use Gnulib's
|
|
<CODE>fnmatch-gnu</CODE> module. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_FORK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
vfork.h This macro checks for the
|
|
<CODE>fork</CODE> and <CODE>vfork</CODE>
|
|
functions. If a working <CODE>fork</CODE> is found,
|
|
define <CODE>HAVE_WORKING_FORK</CODE>. This macro
|
|
checks whether <CODE>fork</CODE> is just a stub by
|
|
trying to run it.</P><P>
|
|
|
|
If <TT>vfork.h</TT> is found, define
|
|
<CODE>HAVE_VFORK_H</CODE>. If a working
|
|
<CODE>vfork</CODE> is found, define
|
|
<CODE>HAVE_WORKING_VFORK</CODE>. Otherwise, define
|
|
<CODE>vfork</CODE> to be
|
|
<CODE>fork</CODE> for backward compatibility with
|
|
previous versions of <CODE>autoconf</CODE>. This
|
|
macro checks for several known errors in implementations of
|
|
<CODE>vfork</CODE> and considers the system to not
|
|
have a working <CODE>vfork</CODE> if it detects any
|
|
of them. It is not considered to be an implementation error if
|
|
a child's invocation of <CODE>signal</CODE> modifies
|
|
the parent's signal handler, since child processes rarely change
|
|
their signal handlers.</P><P>
|
|
|
|
Since this macro defines <CODE>vfork</CODE> only for
|
|
backward compatibility with previous versions of
|
|
<CODE>autoconf</CODE> you're encouraged to define it
|
|
yourself in new code:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group #ifndef HAVE_WORKING_VFORK #
|
|
define vfork fork #endif @end group
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_FSEEKO">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>fseeko</CODE> function is
|
|
available, define <CODE>HAVE_FSEEKO</CODE>. Define
|
|
<CODE>_LARGEFILE_SOURCE</CODE> if necessary to make
|
|
the prototype visible on some systems (e.g., glibc 2.2).
|
|
Otherwise linkage problems may occur when compiling with
|
|
<CODE>AC_SYS_LARGEFILE</CODE> on largefile-sensitive
|
|
systems where <CODE>off_t</CODE> does not default to
|
|
a 64bit entity. All systems with
|
|
<CODE>fseeko</CODE> also supply
|
|
<CODE>ftello</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_GETGROUPS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>getgroups</CODE> function is
|
|
available and works (unlike on Ultrix 4.3, where
|
|
<samp>getgroups (0, 0)</samp> always fails), define
|
|
<CODE>HAVE_GETGROUPS</CODE>. Set
|
|
<CODE>GETGROUPS_LIBS</CODE> to any libraries needed
|
|
to get that function. This macro runs
|
|
<CODE>AC_TYPE_GETGROUPS</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_GETLOADAVG">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check how to get the system load averages. To
|
|
perform its tests properly, this macro needs the file
|
|
<TT>getloadavg.c</TT>; therefore, be sure to set the
|
|
<CODE>AC_LIBOBJ</CODE> replacement directory
|
|
properly (see Generic Functions,
|
|
<CODE>AC_CONFIG_LIBOBJ_DIR</CODE>).</P><P>
|
|
|
|
If the system has the <CODE>getloadavg</CODE>
|
|
function, define <CODE>HAVE_GETLOADAVG</CODE>, and
|
|
set <CODE>GETLOADAVG_LIBS</CODE> to any libraries
|
|
necessary to get that function. Also add
|
|
<CODE>GETLOADAVG_LIBS</CODE> to
|
|
<CODE>LIBS</CODE>. Otherwise, require an
|
|
<CODE>AC_LIBOBJ</CODE> replacement for
|
|
<samp>getloadavg</samp> with source code in
|
|
<TT><VAR>dir</VAR>/getloadavg.c</TT>,
|
|
and possibly define several other C preprocessor macros and
|
|
output variables:</P><P>
|
|
|
|
<OL> <LI> Define
|
|
<CODE>C_GETLOADAVG</CODE>.</P><P>
|
|
|
|
<LI> Define <CODE>SVR4</CODE>,
|
|
<CODE>DGUX</CODE>, <CODE>UMAX</CODE>, or
|
|
<CODE>UMAX4_3</CODE> if on those systems.</P><P>
|
|
|
|
<LI> nlist.h If <TT>nlist.h</TT> is found,
|
|
define <CODE>HAVE_NLIST_H</CODE>.</P><P>
|
|
|
|
<LI> If <samp>struct nlist</samp> has an
|
|
<samp>n_un.n_name</samp> member, define
|
|
<CODE>HAVE_STRUCT_NLIST_N_UN_N_NAME</CODE>. The
|
|
obsolete symbol <CODE>NLIST_NAME_UNION</CODE> is
|
|
still defined, but do not depend upon it.</P><P>
|
|
|
|
<LI> Programs may need to be installed set-group-ID (or
|
|
set-user-ID) for <CODE>getloadavg</CODE> to work.
|
|
In this case, define
|
|
<CODE>GETLOADAVG_PRIVILEGED</CODE>, set the output
|
|
variable <CODE>NEED_SETGID</CODE> to
|
|
<samp>true</samp> (and otherwise to
|
|
<samp>false</samp>), and set
|
|
<CODE>KMEM_GROUP</CODE> to the name of the group
|
|
that should own the installed program. </OL></P><P>
|
|
|
|
The <CODE>AC_FUNC_GETLOADAVG</CODE> macro is
|
|
obsolescent. New programs should use Gnulib's
|
|
<CODE>getloadavg</CODE> module. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_GETMNTENT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check for <CODE>getmntent</CODE> in the standard
|
|
C library, and then in the <TT>sun</TT>,
|
|
<TT>seq</TT>, and <TT>gen</TT>
|
|
libraries, for UNICOS, IRIX 4, PTX, and UnixWare, respectively.
|
|
Then, if <CODE>getmntent</CODE> is available, define
|
|
<CODE>HAVE_GETMNTENT</CODE> and set
|
|
<CODE>ac_cv_func_getmntent</CODE> to
|
|
<CODE>yes</CODE>. Otherwise set
|
|
<CODE>ac_cv_func_getmntent</CODE> to
|
|
<CODE>no</CODE>.</P><P>
|
|
|
|
The result of this macro can be overridden by setting the cache
|
|
variable <CODE>ac_cv_search_getmntent</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_GETPGRP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>GETPGRP_VOID</CODE> if it is an
|
|
error to pass 0 to <CODE>getpgrp</CODE>; this is the
|
|
Posix behavior. On older BSD systems, you must pass 0 to
|
|
<CODE>getpgrp</CODE>, as it takes an argument and
|
|
behaves like Posix's <CODE>getpgid</CODE>.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #ifdef GETPGRP_VOID pid = getpgrp
|
|
(); #else pid = getpgrp (0); #endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro does not check whether
|
|
<CODE>getpgrp</CODE> exists at all; if you need to
|
|
work in that situation, first call
|
|
<CODE>AC_CHECK_FUNC</CODE> for
|
|
<CODE>getpgrp</CODE>.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_getpgrp_void</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current systems have a
|
|
<CODE>getpgrp</CODE> whose signature conforms to
|
|
Posix. New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <TT>link</TT> is a symbolic link, then
|
|
<CODE>lstat</CODE> should treat
|
|
<TT>link/</TT> the same as
|
|
<TT>link/.</TT>. However, many older
|
|
<CODE>lstat</CODE> implementations incorrectly
|
|
ignore trailing slashes.</P><P>
|
|
|
|
It is safe to assume that if <CODE>lstat</CODE>
|
|
incorrectly ignores trailing slashes, then other
|
|
symbolic-link-aware functions like
|
|
<CODE>unlink</CODE> also incorrectly ignore trailing
|
|
slashes.</P><P>
|
|
|
|
If <CODE>lstat</CODE> behaves properly, define
|
|
<CODE>LSTAT_FOLLOWS_SLASHED_SYMLINK</CODE>,
|
|
otherwise require an <CODE>AC_LIBOBJ</CODE>
|
|
replacement of <CODE>lstat</CODE>.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_lstat_dereferences_slashed_symlink</CODE>
|
|
variable.</P><P>
|
|
|
|
The
|
|
<CODE>AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK</CODE>
|
|
macro is obsolescent. New programs should use Gnulib's
|
|
<CODE>lstat</CODE> module. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_MALLOC">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>malloc</CODE> function is
|
|
compatible with the GNU C library
|
|
<CODE>malloc</CODE> (i.e., <samp>malloc
|
|
(0)</samp> returns a valid pointer), define
|
|
<CODE>HAVE_MALLOC</CODE> to 1. Otherwise define
|
|
<CODE>HAVE_MALLOC</CODE> to 0, ask for an
|
|
<CODE>AC_LIBOBJ</CODE> replacement for
|
|
<samp>malloc</samp>, and define
|
|
<CODE>malloc</CODE> to
|
|
<CODE>rpl_malloc</CODE> so that the native
|
|
<CODE>malloc</CODE> is not used in the main project.</P><P>
|
|
|
|
Typically, the replacement file <TT>malloc.c</TT>
|
|
should look like (note the <samp>#undef
|
|
malloc</samp>):</P><P>
|
|
|
|
<CODE> #include <config.h> #undef malloc</P><P>
|
|
|
|
#include <sys/types.h></P><P>
|
|
|
|
void *malloc ();</P><P>
|
|
|
|
/* Allocate an N-byte block of memory from the heap. If N is
|
|
zero, allocate a 1-byte block. */</P><P>
|
|
|
|
void * rpl_malloc (size_t n) { if (n == 0) n = 1; return
|
|
malloc (n); } </CODE></P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_malloc_0_nonnull</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_MBRTOWC">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>HAVE_MBRTOWC</CODE> to 1 if the
|
|
function <CODE>mbrtowc</CODE> and the type
|
|
<CODE>mbstate_t</CODE> are properly declared.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_mbrtowc</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_MEMCMP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>memcmp</CODE> function is not
|
|
available, or does not work on 8-bit data (like the one on SunOS
|
|
4.1.3), or fails when comparing 16 bytes or more and with at
|
|
least one buffer not starting on a 4-byte boundary (such as the
|
|
one on NeXT x86 OpenStep), require an
|
|
<CODE>AC_LIBOBJ</CODE> replacement for
|
|
<samp>memcmp</samp>.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_memcmp_working</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current systems have a working
|
|
<CODE>memcmp</CODE>. New programs need not use this
|
|
macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_MKTIME">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>mktime</CODE> function is not
|
|
available, or does not work correctly, require an
|
|
<CODE>AC_LIBOBJ</CODE> replacement for
|
|
<samp>mktime</samp>. For the purposes of this test,
|
|
<CODE>mktime</CODE> should conform to the Posix
|
|
standard and should be the inverse of
|
|
<CODE>localtime</CODE>.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_working_mktime</CODE> variable.</P><P>
|
|
|
|
The <CODE>AC_FUNC_MKTIME</CODE> macro is
|
|
obsolescent. New programs should use Gnulib's
|
|
<CODE>mktime</CODE> module. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_MMAP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>mmap</CODE> function exists and
|
|
works correctly, define <CODE>HAVE_MMAP</CODE>.
|
|
This checks only private fixed mapping of already-mapped memory.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_mmap_fixed_mapped</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_OBSTACK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the obstacks are found, define
|
|
<CODE>HAVE_OBSTACK</CODE>, else require an
|
|
<CODE>AC_LIBOBJ</CODE> replacement for
|
|
<samp>obstack</samp>.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_obstack</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_REALLOC">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>realloc</CODE> function is
|
|
compatible with the GNU C library
|
|
<CODE>realloc</CODE> (i.e., <samp>realloc
|
|
(NULL, 0)</samp> returns a valid pointer), define
|
|
<CODE>HAVE_REALLOC</CODE> to 1. Otherwise define
|
|
<CODE>HAVE_REALLOC</CODE> to 0, ask for an
|
|
<CODE>AC_LIBOBJ</CODE> replacement for
|
|
<samp>realloc</samp>, and define
|
|
<CODE>realloc</CODE> to
|
|
<CODE>rpl_realloc</CODE> so that the native
|
|
<CODE>realloc</CODE> is not used in the main
|
|
project. See <CODE>AC_FUNC_MALLOC</CODE> for
|
|
details.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_realloc_0_nonnull</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_SELECT_ARGTYPES">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Determines the correct type to be passed for each of the
|
|
<CODE>select</CODE> function's arguments, and
|
|
defines those types in
|
|
<CODE>SELECT_TYPE_ARG1</CODE>,
|
|
<CODE>SELECT_TYPE_ARG234</CODE>, and
|
|
<CODE>SELECT_TYPE_ARG5</CODE> respectively.
|
|
<CODE>SELECT_TYPE_ARG1</CODE> defaults to
|
|
<samp>int</samp>,
|
|
<CODE>SELECT_TYPE_ARG234</CODE> defaults to
|
|
<samp>int *</samp>, and
|
|
<CODE>SELECT_TYPE_ARG5</CODE> defaults to
|
|
<samp>struct timeval *</samp>.</P><P>
|
|
|
|
This macro is obsolescent, as current systems have a
|
|
<CODE>select</CODE> whose signature conforms to
|
|
Posix. New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_SETPGRP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>setpgrp</CODE> takes no argument (the
|
|
Posix version), define <CODE>SETPGRP_VOID</CODE>.
|
|
Otherwise, it is the BSD version, which takes two process IDs as
|
|
arguments. This macro does not check whether
|
|
<CODE>setpgrp</CODE> exists at all; if you need to
|
|
work in that situation, first call
|
|
<CODE>AC_CHECK_FUNC</CODE> for
|
|
<CODE>setpgrp</CODE>.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_setpgrp_void</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current systems have a
|
|
<CODE>setpgrp</CODE> whose signature conforms to
|
|
Posix. New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_STAT">
|
|
<prototype>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine whether <CODE>stat</CODE> or
|
|
<CODE>lstat</CODE> have the bug that it succeeds
|
|
when given the zero-length file name as argument. The
|
|
<CODE>stat</CODE> and <CODE>lstat</CODE>
|
|
from SunOS 4.1.4 and the Hurd (as of 1998-11-01) do this.</P><P>
|
|
|
|
If it does, then define
|
|
<CODE>HAVE_STAT_EMPTY_STRING_BUG</CODE> (or
|
|
<CODE>HAVE_LSTAT_EMPTY_STRING_BUG</CODE>) and ask
|
|
for an <CODE>AC_LIBOBJ</CODE> replacement of it.</P><P>
|
|
|
|
The results of these macros are cached in the
|
|
<CODE>ac_cv_func_stat_empty_string_bug</CODE> and
|
|
the <CODE>ac_cv_func_lstat_empty_string_bug</CODE>
|
|
variables, respectively.</P><P>
|
|
|
|
These macros are obsolescent, as no current systems have the
|
|
bug. New programs need not use these macros.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_STRCOLL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>strcoll</CODE> function exists and
|
|
works correctly, define <CODE>HAVE_STRCOLL</CODE>.
|
|
This does a bit more than
|
|
<samp>AC_CHECK_FUNCS(strcoll)</samp>, because some
|
|
systems have incorrect definitions of
|
|
<CODE>strcoll</CODE> that should not be used.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_strcoll_works</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_STRERROR_R">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>strerror_r</CODE> is available,
|
|
define <CODE>HAVE_STRERROR_R</CODE>, and if it is
|
|
declared, define <CODE>HAVE_DECL_STRERROR_R</CODE>.
|
|
If it returns a <CODE>char *</CODE> message, define
|
|
<CODE>STRERROR_R_CHAR_P</CODE>; otherwise it returns
|
|
an <CODE>int</CODE> error number. The Thread-Safe
|
|
Functions option of Posix requires
|
|
<CODE>strerror_r</CODE> to return
|
|
<CODE>int</CODE>, but many systems (including, for
|
|
example, version 2.2.4 of the GNU C Library) return a
|
|
<CODE>char *</CODE> value that is not necessarily
|
|
equal to the buffer argument.</P><P>
|
|
|
|
The result of this macro is cached in the
|
|
<CODE>ac_cv_func_strerror_r_char_p</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_STRFTIME">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check for <CODE>strftime</CODE> in the
|
|
<TT>intl</TT> library, for SCO Unix. Then, if
|
|
<CODE>strftime</CODE> is available, define
|
|
<CODE>HAVE_STRFTIME</CODE>.</P><P>
|
|
|
|
This macro is obsolescent, as no current systems require the
|
|
<TT>intl</TT> library for
|
|
<CODE>strftime</CODE>. New programs need not use
|
|
this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_STRTOD">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>strtod</CODE> function does not
|
|
exist or doesn't work correctly, ask for an
|
|
<CODE>AC_LIBOBJ</CODE> replacement of
|
|
<samp>strtod</samp>. In this case, because
|
|
<TT>strtod.c</TT> is likely to need
|
|
<samp>pow</samp>, set the output variable
|
|
<CODE>POW_LIB</CODE> to the extra library needed.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_func_strtod</CODE> variable and depends
|
|
upon the result in the <CODE>ac_cv_func_pow</CODE>
|
|
variable.</P><P>
|
|
|
|
The <CODE>AC_FUNC_STRTOD</CODE> macro is
|
|
obsolescent. New programs should use Gnulib's
|
|
<CODE>strtod</CODE> module. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_STRTOLD">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>strtold</CODE> function exists and
|
|
conforms to C99, define <CODE>HAVE_STRTOLD</CODE>.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_func_strtold</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_STRNLEN">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the <CODE>strnlen</CODE> function is not
|
|
available, or is buggy (like the one from AIX 4.3), require an
|
|
<CODE>AC_LIBOBJ</CODE> replacement for it.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_func_strnlen_working</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_UTIME_NULL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <samp>utime (<VAR>file</VAR>,
|
|
NULL)</samp> sets <VAR>file</VAR>'s timestamp
|
|
to the present, define <CODE>HAVE_UTIME_NULL</CODE>.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_func_utime_null</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as all current systems have a
|
|
<CODE>utime</CODE> that behaves this way. New
|
|
programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_VPRINTF">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>vprintf</CODE> is found, define
|
|
<CODE>HAVE_VPRINTF</CODE>. Otherwise, if
|
|
<CODE>_doprnt</CODE> is found, define
|
|
<CODE>HAVE_DOPRNT</CODE>. (If
|
|
<CODE>vprintf</CODE> is available, you may assume
|
|
that <CODE>vfprintf</CODE> and
|
|
<CODE>vsprintf</CODE> are also available.)</P><P>
|
|
|
|
This macro is obsolescent, as all current systems have
|
|
<CODE>vprintf</CODE>. New programs need not use this
|
|
macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_REPLACE_FNMATCH">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
fnmatch.h If the <CODE>fnmatch</CODE> function
|
|
does not conform to Posix (see
|
|
<CODE>AC_FUNC_FNMATCH</CODE>), ask for its
|
|
<CODE>AC_LIBOBJ</CODE> replacement.</P><P>
|
|
|
|
The files <TT>fnmatch.c</TT>,
|
|
<TT>fnmatch_loop.c</TT>, and
|
|
<TT>fnmatch_.h</TT> in the
|
|
<CODE>AC_LIBOBJ</CODE> replacement directory are
|
|
assumed to contain a copy of the source code of GNU
|
|
<CODE>fnmatch</CODE>. If necessary, this source
|
|
code is compiled as an <CODE>AC_LIBOBJ</CODE>
|
|
replacement, and the <TT>fnmatch_.h</TT> file is
|
|
linked to <TT>fnmatch.h</TT> so that it can be
|
|
included in place of the system
|
|
<CODE><fnmatch.h></CODE>.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_func_fnmatch_works</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as it assumes the use of particular
|
|
source files. New programs should use Gnulib's
|
|
<CODE>fnmatch-posix</CODE> module, which provides
|
|
this macro along with the source files. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_FUNC">
|
|
<prototype>
|
|
<parameter content="function"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If C function <VAR>function</VAR> is available,
|
|
run shell commands <VAR>action-if-found</VAR>,
|
|
otherwise <VAR>action-if-not-found</VAR>. If you
|
|
just want to define a symbol if the function is available,
|
|
consider using <CODE>AC_CHECK_FUNCS</CODE> instead.
|
|
This macro checks for functions with C linkage even when
|
|
<CODE>AC_LANG(C++)</CODE> has been called, since C
|
|
is more standardized than C++. (Language Choice, for more
|
|
information about selecting the language for checks.)</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_func_<VAR>function</VAR></CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_FUNCS">
|
|
<prototype>
|
|
<parameter content="function..."/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each <VAR>function</VAR> enumerated in the
|
|
blank-or-newline-separated argument list, define
|
|
<CODE>HAVE_<VAR>function</VAR></CODE>
|
|
(in all capitals) if it is available. If
|
|
<VAR>action-if-found</VAR> is given, it is
|
|
additional shell code to execute when one of the functions is
|
|
found. You can give it a value of
|
|
<samp>break</samp> to break out of the loop on the
|
|
first match. If <VAR>action-if-not-found</VAR> is
|
|
given, it is executed when one of the functions is not found.</P><P>
|
|
|
|
Results are cached for each <VAR>function</VAR> as
|
|
in <CODE>AC_CHECK_FUNC</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_FUNCS_ONCE">
|
|
<prototype>
|
|
<parameter content="function..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each <VAR>function</VAR> enumerated in the
|
|
blank-or-newline-separated argument list, define
|
|
<CODE>HAVE_<VAR>function</VAR></CODE>
|
|
(in all capitals) if it is available. This is a once-only
|
|
variant of <CODE>AC_CHECK_FUNCS</CODE>. It
|
|
generates the checking code at most once, so that
|
|
<CODE>configure</CODE> is smaller and faster; but
|
|
the checks cannot be conditionalized and are always done once,
|
|
early during the <CODE>configure</CODE> run.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LIBOBJ">
|
|
<prototype>
|
|
<parameter content="function"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Specify that
|
|
<samp><VAR>function</VAR>.c</samp> must
|
|
be included in the executables to replace a missing or broken
|
|
implementation of <VAR>function</VAR>.</P><P>
|
|
|
|
Technically, it adds
|
|
<samp><VAR>function</VAR>.$ac_objext</samp>
|
|
to the output variable <CODE>LIBOBJS</CODE> if it is
|
|
not already in, and calls <CODE>AC_LIBSOURCE</CODE>
|
|
for <samp><VAR>function</VAR>.c</samp>.
|
|
You should not directly change <CODE>LIBOBJS</CODE>,
|
|
since this is not traceable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LIBSOURCE">
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Specify that <VAR>file</VAR> might be needed to
|
|
compile the project. If you need to know what files might be
|
|
needed by a <TT>configure.ac</TT>, you should trace
|
|
<CODE>AC_LIBSOURCE</CODE>.
|
|
<VAR>file</VAR> must be a literal.</P><P>
|
|
|
|
This macro is called automatically from
|
|
<CODE>AC_LIBOBJ</CODE>, but you must call it
|
|
explicitly if you pass a shell variable to
|
|
<CODE>AC_LIBOBJ</CODE>. In that case, since shell
|
|
variables cannot be traced statically, you must pass to
|
|
<CODE>AC_LIBSOURCE</CODE> any possible files that
|
|
the shell variable might cause
|
|
<CODE>AC_LIBOBJ</CODE> to need. For example, if you
|
|
want to pass a variable <CODE>$foo_or_bar</CODE> to
|
|
<CODE>AC_LIBOBJ</CODE> that holds either
|
|
<CODE>"foo"</CODE> or
|
|
<CODE>"bar"</CODE>, you should do:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_LIBSOURCE([foo.c])
|
|
AC_LIBSOURCE([bar.c]) AC_LIBOBJ([$foo_or_bar])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
There is usually a way to avoid this, however, and you are
|
|
encouraged to simply call <CODE>AC_LIBOBJ</CODE>
|
|
with literal arguments.</P><P>
|
|
|
|
Note that this macro replaces the obsolete
|
|
<CODE>AC_LIBOBJ_DECL</CODE>, with slightly different
|
|
semantics: the old macro took the function name, e.g.,
|
|
<CODE>foo</CODE>, as its argument rather than the
|
|
file name.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LIBSOURCES">
|
|
<prototype>
|
|
<parameter content="files"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_LIBSOURCE</CODE>, but accepts one or
|
|
more <VAR>files</VAR> in a comma-separated M4 list.
|
|
Thus, the above example might be rewritten:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_LIBSOURCES([foo.c, bar.c])
|
|
AC_LIBOBJ([$foo_or_bar])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_LIBOBJ_DIR">
|
|
<prototype>
|
|
<parameter content="directory"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Specify that <CODE>AC_LIBOBJ</CODE> replacement
|
|
files are to be found in <VAR>directory</VAR>, a
|
|
name relative to the top level of the source tree. The
|
|
replacement directory defaults to <TT>.</TT>, the
|
|
top level directory, and the most typical value is
|
|
<TT>lib</TT>, corresponding to
|
|
<samp>AC_CONFIG_LIBOBJ_DIR([lib])</samp>.</P><P>
|
|
|
|
<CODE>configure</CODE> might need to know the
|
|
replacement directory for the following reasons: (i) some checks
|
|
use the replacement files, (ii) some macros bypass broken system
|
|
headers by installing links to the replacement headers (iii)
|
|
when used in conjunction with Automake, within each makefile,
|
|
<VAR>directory</VAR> is used as a relative path from
|
|
<CODE>$(top_srcdir)</CODE> to each object named in
|
|
<CODE>LIBOBJS</CODE> and
|
|
<CODE>LTLIBOBJS</CODE>, etc.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_REPLACE_FUNCS">
|
|
<prototype>
|
|
<parameter content="function..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_CHECK_FUNCS</CODE>, but uses
|
|
<samp>AC_LIBOBJ(<VAR>function</VAR>)</samp>
|
|
as <VAR>action-if-not-found</VAR>. You can declare
|
|
your replacement function by enclosing the prototype in
|
|
<samp>#ifndef
|
|
HAVE_<VAR>function</VAR></samp>. If the
|
|
system has the function, it probably declares it in a header
|
|
file you should be including, so you shouldn't redeclare it lest
|
|
your declaration conflict.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_ASSERT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
assert.h Check whether to enable assertions in the style of
|
|
<TT>assert.h</TT>. Assertions are enabled by
|
|
default, but the user can override this by invoking
|
|
<CODE>configure</CODE> with the
|
|
<samp>--disable-assert</samp> option.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_DIRENT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
dirent.h sys/ndir.h sys/dir.h ndir.h Check for the
|
|
following header files. For the first one that is found and
|
|
defines <samp>DIR</samp>, define the listed C
|
|
preprocessor macro:</P><P>
|
|
|
|
@multitable {<TT>sys/ndir.h</TT>}
|
|
{<CODE>HAVE_SYS_NDIR_H</CODE>} <LI>
|
|
<TT>dirent.h</TT> @tab
|
|
<CODE>HAVE_DIRENT_H</CODE> <LI>
|
|
<TT>sys/ndir.h</TT> @tab
|
|
<CODE>HAVE_SYS_NDIR_H</CODE> <LI>
|
|
<TT>sys/dir.h</TT> @tab
|
|
<CODE>HAVE_SYS_DIR_H</CODE> <LI>
|
|
<TT>ndir.h</TT> @tab
|
|
<CODE>HAVE_NDIR_H</CODE> @end multitable</P><P>
|
|
|
|
The directory-library declarations in your source code should
|
|
look something like the following:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group #include <sys/types.h>
|
|
#ifdef HAVE_DIRENT_H # include <dirent.h> # define
|
|
NAMLEN(dirent) strlen ((dirent)->d_name) #else # define
|
|
dirent direct # define NAMLEN(dirent) ((dirent)->d_namlen) #
|
|
ifdef HAVE_SYS_NDIR_H # include <sys/ndir.h> # endif #
|
|
ifdef HAVE_SYS_DIR_H # include <sys/dir.h> # endif #
|
|
ifdef HAVE_NDIR_H # include <ndir.h> # endif #endif @end
|
|
group </pre></td></tr></table></P><P>
|
|
|
|
Using the above declarations, the program would declare
|
|
variables to be of type <CODE>struct dirent</CODE>,
|
|
not <CODE>struct direct</CODE>, and would access the
|
|
length of a directory entry name by passing a pointer to a
|
|
<CODE>struct dirent</CODE> to the
|
|
<CODE>NAMLEN</CODE> macro.</P><P>
|
|
|
|
This macro also checks for the SCO Xenix
|
|
<TT>dir</TT> and <TT>x</TT> libraries.</P><P>
|
|
|
|
This macro is obsolescent, as all current systems with directory
|
|
libraries have <CODE><dirent.h></CODE>. New
|
|
programs need not use this macro.</P><P>
|
|
|
|
Also see <CODE>AC_STRUCT_DIRENT_D_INO</CODE> and
|
|
<CODE>AC_STRUCT_DIRENT_D_TYPE</CODE> (Particular
|
|
Structures).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_MAJOR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
sys/mkdev.h sys/sysmacros.h If
|
|
<TT>sys/types.h</TT> does not define
|
|
<CODE>major</CODE>, <CODE>minor</CODE>,
|
|
and <CODE>makedev</CODE>, but
|
|
<TT>sys/mkdev.h</TT> does, define
|
|
<CODE>MAJOR_IN_MKDEV</CODE>; otherwise, if
|
|
<TT>sys/sysmacros.h</TT> does, define
|
|
<CODE>MAJOR_IN_SYSMACROS</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_RESOLV">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
resolv.h Checks for header <TT>resolv.h</TT>,
|
|
checking for prerequisites first. To properly use
|
|
<TT>resolv.h</TT>, your code should contain
|
|
something like the following:</P><P>
|
|
|
|
<CODE> #ifdef HAVE_SYS_TYPES_H # include
|
|
<sys/types.h> #endif #ifdef HAVE_NETINET_IN_H # include
|
|
<netinet/in.h> /* inet_ functions / structs */ #endif
|
|
#ifdef HAVE_ARPA_NAMESER_H # include <arpa/nameser.h> /*
|
|
DNS HEADER struct */ #endif #ifdef HAVE_NETDB_H # include
|
|
<netdb.h> #endif #include <resolv.h> </CODE>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_STAT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
sys/stat.h If the macros <CODE>S_ISDIR</CODE>,
|
|
<CODE>S_ISREG</CODE>, etc.@: defined in
|
|
<TT>sys/stat.h</TT> do not work properly (returning
|
|
false positives), define
|
|
<CODE>STAT_MACROS_BROKEN</CODE>. This is the case
|
|
on Tektronix UTekV, Amdahl UTS and Motorola System V/88.</P><P>
|
|
|
|
This macro is obsolescent, as no current systems have the bug.
|
|
New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_STDBOOL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
stdbool.h system.h If <TT>stdbool.h</TT> exists
|
|
and conforms to C99, define
|
|
<CODE>HAVE_STDBOOL_H</CODE> to 1; if the type
|
|
<CODE>_Bool</CODE> is defined, define
|
|
<CODE>HAVE__BOOL</CODE> to 1. To fulfill the C99
|
|
requirements, your <TT>system.h</TT> could contain
|
|
the following code:</P><P>
|
|
|
|
<CODE> #ifdef HAVE_STDBOOL_H # include <stdbool.h>
|
|
#else # ifndef HAVE__BOOL # ifdef __cplusplus typedef bool
|
|
_Bool; # else # define _Bool signed char # endif # endif #
|
|
define bool _Bool # define false 0 # define true 1 # define
|
|
__bool_true_false_are_defined 1 #endif </CODE></P><P>
|
|
|
|
Alternatively you can use the <samp>stdbool</samp>
|
|
package of Gnulib (Gnulib); it packages the above code into a
|
|
replacement header and contains a few other bells and whistles.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_header_stdbool_h</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_STDC">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
stdlib.h stdarg.h string.h float.h ctype.h Define
|
|
<CODE>STDC_HEADERS</CODE> if the system has C header
|
|
files conforming to ANSI C89 (ISO C90). Specifically, this macro
|
|
checks for <TT>stdlib.h</TT>,
|
|
<TT>stdarg.h</TT>, <TT>string.h</TT>,
|
|
and <TT>float.h</TT>; if the system has those, it
|
|
probably has the rest of the C89 header files. This macro also
|
|
checks whether <TT>string.h</TT> declares
|
|
<CODE>memchr</CODE> (and thus presumably the other
|
|
<CODE>mem</CODE> functions), whether
|
|
<TT>stdlib.h</TT> declare
|
|
<CODE>free</CODE> (and thus presumably
|
|
<CODE>malloc</CODE> and other related functions),
|
|
and whether the <TT>ctype.h</TT> macros work on
|
|
characters with the high bit set, as the C standard requires.</P><P>
|
|
|
|
If you use this macro, your code can refer to
|
|
<CODE>STDC_HEADERS</CODE> to determine whether the
|
|
system has conforming header files (and probably C library
|
|
functions).</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_header_stdc</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current systems have conforming
|
|
header files. New programs need not use this macro.</P><P>
|
|
|
|
string.h strings.h Nowadays <TT>string.h</TT> is
|
|
part of the C standard and declares functions like
|
|
<CODE>strcpy</CODE>, and
|
|
<TT>strings.h</TT> is standardized by Posix and
|
|
declares BSD functions like <CODE>bcopy</CODE>; but
|
|
historically, string functions were a major sticking point in
|
|
this area. If you still want to worry about portability to
|
|
ancient systems without standard headers, there is so much
|
|
variation that it is probably easier to declare the functions
|
|
you use than to figure out exactly what the system header files
|
|
declare. Some ancient systems contained a mix of functions from
|
|
the C standard and from BSD; some were mostly standard but
|
|
lacked <samp>memmove</samp>; some defined the BSD
|
|
functions as macros in <TT>string.h</TT> or
|
|
<TT>strings.h</TT>; some had only the BSD functions
|
|
but <TT>string.h</TT>; some declared the memory
|
|
functions in <TT>memory.h</TT>, some in
|
|
<TT>string.h</TT>; etc. It is probably sufficient
|
|
to check for one string function and one memory function; if the
|
|
library had the standard versions of those then it probably had
|
|
most of the others. If you put the following in
|
|
<TT>configure.ac</TT>:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> # This example is obsolescent. #
|
|
Nowadays you can omit these macro calls. AC_HEADER_STDC
|
|
AC_CHECK_FUNCS([strchr memcpy])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
then, in your code, you can use declarations like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group /* This example is
|
|
obsolescent. Nowadays you can just #include <string.h>.
|
|
*/ #ifdef STDC_HEADERS # include <string.h> #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
|
|
@end group </pre></td></tr></table></P><P>
|
|
|
|
If you use a function like <CODE>memchr</CODE>,
|
|
<CODE>memset</CODE>,
|
|
<CODE>strtok</CODE>, or
|
|
<CODE>strspn</CODE>, which have no BSD equivalent,
|
|
then macros don't suffice to port to ancient hosts; you must
|
|
provide an implementation of each function. An easy way to
|
|
incorporate your implementations only when needed (since the
|
|
ones in system C libraries may be hand optimized) is to, taking
|
|
<CODE>memchr</CODE> for example, put it in
|
|
<TT>memchr.c</TT> and use
|
|
<samp>AC_REPLACE_FUNCS([memchr])</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_SYS_WAIT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
sys/wait.h If <TT>sys/wait.h</TT> exists and is
|
|
compatible with Posix, define
|
|
<CODE>HAVE_SYS_WAIT_H</CODE>. Incompatibility can
|
|
occur if <TT>sys/wait.h</TT> does not exist, or if
|
|
it uses the old BSD <CODE>union wait</CODE> instead
|
|
of <CODE>int</CODE> to store a status value. If
|
|
<TT>sys/wait.h</TT> is not Posix compatible, then
|
|
instead of including it, define the Posix macros with their
|
|
usual interpretations. Here is an example:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group #include <sys/types.h>
|
|
#ifdef HAVE_SYS_WAIT_H # include <sys/wait.h> #endif
|
|
#ifndef WEXITSTATUS # define WEXITSTATUS(stat_val) ((unsigned
|
|
int) (stat_val) >> 8) #endif #ifndef WIFEXITED # define
|
|
WIFEXITED(stat_val) (((stat_val) & 255) == 0) #endif @end
|
|
group </pre></td></tr></table></P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_header_sys_wait_h</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current systems are compatible
|
|
with Posix. New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_TIME">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
time.h sys/time.h If a program may include both
|
|
<TT>time.h</TT> and <TT>sys/time.h</TT>,
|
|
define <CODE>TIME_WITH_SYS_TIME</CODE>. On some
|
|
ancient systems, <TT>sys/time.h</TT> included
|
|
<TT>time.h</TT>, but <TT>time.h</TT> was
|
|
not protected against multiple inclusion, so programs could not
|
|
explicitly include both files. This macro is useful in programs
|
|
that use, for example, <CODE>struct timeval</CODE>
|
|
as well as <CODE>struct tm</CODE>. It is best used
|
|
in conjunction with <CODE>HAVE_SYS_TIME_H</CODE>,
|
|
which can be checked for using
|
|
<CODE>AC_CHECK_HEADERS([sys/time.h])</CODE>.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group #ifdef TIME_WITH_SYS_TIME #
|
|
include <sys/time.h> # include <time.h> #else #
|
|
ifdef HAVE_SYS_TIME_H # include <sys/time.h> # else #
|
|
include <time.h> # endif #endif @end group
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_header_time</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current systems can include both
|
|
files when they exist. New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_TIOCGWINSZ">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
sys/ioctl.h termios.h If the use of
|
|
<CODE>TIOCGWINSZ</CODE> requires
|
|
<TT><sys/ioctl.h></TT>, then define
|
|
<CODE>GWINSZ_IN_SYS_IOCTL</CODE>. Otherwise
|
|
<CODE>TIOCGWINSZ</CODE> can be found in
|
|
<TT><termios.h></TT>.</P><P>
|
|
|
|
Use:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group #ifdef HAVE_TERMIOS_H #
|
|
include <termios.h> #endif</P><P>
|
|
|
|
#ifdef GWINSZ_IN_SYS_IOCTL # include <sys/ioctl.h> #endif
|
|
@end group </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_HEADER">
|
|
<prototype>
|
|
<parameter content="header-file"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
<parameter content="[includes]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
-file} If the system header file
|
|
<VAR>header-file</VAR> is compilable, execute shell
|
|
commands <VAR>action-if-found</VAR>, otherwise
|
|
execute <VAR>action-if-not-found</VAR>. If you just
|
|
want to define a symbol if the header file is available,
|
|
consider using <CODE>AC_CHECK_HEADERS</CODE>
|
|
instead.</P><P>
|
|
|
|
<VAR>includes</VAR> is decoded to determine the
|
|
appropriate include directives. If omitted or empty,
|
|
<TT>configure</TT> will check for both header
|
|
existence (with the preprocessor) and usability (with the
|
|
compiler), using <CODE>AC_INCLUDES_DEFAULT</CODE>
|
|
for the compile test. If there is a discrepancy between the
|
|
results, a warning is issued to the user, and the compiler
|
|
results are favored (Present But Cannot Be Compiled). In
|
|
general, favoring the compiler results means that a header will
|
|
be treated as not found even though the file exists, because you
|
|
did not provide enough prerequisites.</P><P>
|
|
|
|
Providing a non-empty <VAR>includes</VAR> argument
|
|
allows the code to provide any prerequisites prior to including
|
|
the header under test; it is common to use the argument
|
|
<CODE>AC_INCLUDES_DEFAULT</CODE> (Default Includes).
|
|
With an explicit fourth argument, no preprocessor test is
|
|
needed. As a special case, an <VAR>includes</VAR>
|
|
of exactly <samp>-</samp> triggers the older
|
|
preprocessor check, which merely determines existence of the
|
|
file in the preprocessor search path; this should only be used
|
|
as a last resort (it is safer to determine the actual
|
|
prerequisites and perform a compiler check, or else use
|
|
<CODE>AC_PREPROC_IFELSE</CODE> to make it obvious
|
|
that only a preprocessor check is desired).</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_header_<VAR>header-file</VAR></CODE>
|
|
variable, with characters not suitable for a variable name
|
|
mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_HEADERS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
action-if-found, action-if-not-found, @ includes) -file}
|
|
For each given system header file
|
|
<VAR>header-file</VAR> in the blank-separated
|
|
argument list that exists, define
|
|
<CODE>HAVE_<VAR>header-file</VAR></CODE>
|
|
(in all capitals). If <VAR>action-if-found</VAR> is
|
|
given, it is additional shell code to execute when one of the
|
|
header files is found. You can give it a value of
|
|
<samp>break</samp> to break out of the loop on the
|
|
first match. If <VAR>action-if-not-found</VAR> is
|
|
given, it is executed when one of the header files is not found.</P><P>
|
|
|
|
<VAR>includes</VAR> is interpreted as in
|
|
<CODE>AC_CHECK_HEADER</CODE>, in order to choose the
|
|
set of preprocessor directives supplied before the header under
|
|
test.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_header_<VAR>header-file</VAR></CODE>
|
|
variable, with characters not suitable for a variable name
|
|
mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_HEADERS_ONCE">
|
|
<prototype>
|
|
<parameter content="header-file..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each given system header file
|
|
<VAR>header-file</VAR> in the blank-separated
|
|
argument list that exists, define
|
|
<CODE>HAVE_<VAR>header-file</VAR></CODE>
|
|
(in all capitals). This is a once-only variant of
|
|
<CODE>AC_CHECK_HEADERS</CODE>. It generates the
|
|
checking code at most once, so that
|
|
<CODE>configure</CODE> is smaller and faster; but
|
|
the checks cannot be conditionalized and are always done once,
|
|
early during the <CODE>configure</CODE> run. Thus,
|
|
this macro is only safe for checking headers that do not have
|
|
prerequisites beyond what
|
|
<CODE>AC_INCLUDES_DEFAULT</CODE> provides.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_DECL">
|
|
<prototype>
|
|
<parameter content="symbol"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
<parameter content="[includes= AC_INCLUDES_DEFAULT]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If <VAR>symbol</VAR> (a function, variable, or
|
|
constant) is not declared in <VAR>includes</VAR> and
|
|
a declaration is needed, run the shell commands
|
|
<VAR>action-if-not-found</VAR>, otherwise
|
|
<VAR>action-if-found</VAR>.
|
|
<VAR>includes</VAR> is a series of include
|
|
directives, defaulting to
|
|
<CODE>AC_INCLUDES_DEFAULT</CODE> (Default Includes),
|
|
which are used prior to the declaration under test.</P><P>
|
|
|
|
This macro actually tests whether <VAR>symbol</VAR>
|
|
is defined as a macro or can be used as an r-value, not whether
|
|
it is really declared, because it is much safer to avoid
|
|
introducing extra declarations when they are not needed. In
|
|
order to facilitate use of C++ and overloaded function
|
|
declarations, it is possible to specify function argument types
|
|
in parentheses for types which can be zero-initialized:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_DECL([basename(char *)])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_have_decl_<VAR>symbol</VAR></CODE>
|
|
variable, with characters not suitable for a variable name
|
|
mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_DECLS">
|
|
<prototype>
|
|
<parameter content="symbols"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
<parameter content="[includes= AC_INCLUDES_DEFAULT]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each of the <VAR>symbols</VAR>
|
|
(<EM>comma</EM>-separated list with optional
|
|
function argument types for C++ overloads), define
|
|
<CODE>HAVE_DECL_<VAR>symbol</VAR></CODE>
|
|
(in all capitals) to <samp>1</samp> if
|
|
<VAR>symbol</VAR> is declared, otherwise to
|
|
<samp>0</samp>. If
|
|
<VAR>action-if-not-found</VAR> is given, it is
|
|
additional shell code to execute when one of the function
|
|
declarations is needed, otherwise
|
|
<VAR>action-if-found</VAR> is executed.</P><P>
|
|
|
|
<VAR>includes</VAR> is a series of include
|
|
directives, defaulting to
|
|
<CODE>AC_INCLUDES_DEFAULT</CODE> (Default Includes),
|
|
which are used prior to the declarations under test.</P><P>
|
|
|
|
This macro uses an M4 list as first argument:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_DECLS([strdup])
|
|
AC_CHECK_DECLS([strlen]) AC_CHECK_DECLS([malloc, realloc,
|
|
calloc, free]) AC_CHECK_DECLS([j0], [], [], [[#include
|
|
<math.h>]]) AC_CHECK_DECLS([[basename(char *)],
|
|
[dirname(char *)]])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Unlike the other <samp>AC_CHECK_*S</samp> macros,
|
|
when a <VAR>symbol</VAR> is not declared,
|
|
<CODE>HAVE_DECL_<VAR>symbol</VAR></CODE>
|
|
is defined to <samp>0</samp> instead of leaving
|
|
<CODE>HAVE_DECL_<VAR>symbol</VAR></CODE>
|
|
undeclared. When you are <EM>sure</EM> that the
|
|
check was performed, use
|
|
<CODE>HAVE_DECL_<VAR>symbol</VAR></CODE>
|
|
in <CODE>#if</CODE>:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #if !HAVE_DECL_SYMBOL extern char
|
|
*symbol; #endif </pre></td></tr></table></P><P>
|
|
|
|
If the test may have not been performed, however, because it is
|
|
safer <EM>not</EM> to declare a symbol than to use a
|
|
declaration that conflicts with the system's one, you should
|
|
use:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #if defined HAVE_DECL_MALLOC
|
|
&& !HAVE_DECL_MALLOC void *malloc (size_t *s); #endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You fall into the second category only in extreme situations:
|
|
either your files may be used without being configured, or they
|
|
are used during the configuration. In most cases the
|
|
traditional approach is enough.</P><P>
|
|
|
|
This macro caches its results in
|
|
<CODE>ac_cv_have_decl_<VAR>symbol</VAR></CODE>
|
|
variables, with characters not suitable for a variable name
|
|
mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_DECLS_ONCE">
|
|
<prototype>
|
|
<parameter content="symbols"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each of the <VAR>symbols</VAR>
|
|
(<EM>comma</EM>-separated list), define
|
|
<CODE>HAVE_DECL_<VAR>symbol</VAR></CODE>
|
|
(in all capitals) to <samp>1</samp> if
|
|
<VAR>symbol</VAR> is declared in the default include
|
|
files, otherwise to <samp>0</samp>. This is a
|
|
once-only variant of <CODE>AC_CHECK_DECLS</CODE>.
|
|
It generates the checking code at most once, so that
|
|
<CODE>configure</CODE> is smaller and faster; but
|
|
the checks cannot be conditionalized and are always done once,
|
|
early during the <CODE>configure</CODE> run.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRUCT_DIRENT_D_INO">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Perform all the actions of
|
|
<CODE>AC_HEADER_DIRENT</CODE> (Particular Headers).
|
|
Then, if <CODE>struct dirent</CODE> contains a
|
|
<CODE>d_ino</CODE> member, define
|
|
<CODE>HAVE_STRUCT_DIRENT_D_INO</CODE>.</P><P>
|
|
|
|
<CODE>HAVE_STRUCT_DIRENT_D_INO</CODE> indicates only
|
|
the presence of <CODE>d_ino</CODE>, not whether its
|
|
contents are always reliable. Traditionally, a zero
|
|
<CODE>d_ino</CODE> indicated a deleted directory
|
|
entry, though current systems hide this detail from the user and
|
|
never return zero <CODE>d_ino</CODE> values. Many
|
|
current systems report an incorrect
|
|
<CODE>d_ino</CODE> for a directory entry that is a
|
|
mount point.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRUCT_DIRENT_D_TYPE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Perform all the actions of
|
|
<CODE>AC_HEADER_DIRENT</CODE> (Particular Headers).
|
|
Then, if <CODE>struct dirent</CODE> contains a
|
|
<CODE>d_type</CODE> member, define
|
|
<CODE>HAVE_STRUCT_DIRENT_D_TYPE</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRUCT_ST_BLOCKS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>struct stat</CODE> contains an
|
|
<CODE>st_blocks</CODE> member, define
|
|
<CODE>HAVE_STRUCT_STAT_ST_BLOCKS</CODE>. Otherwise,
|
|
require an <CODE>AC_LIBOBJ</CODE> replacement of
|
|
<samp>fileblocks</samp>. The former name,
|
|
<CODE>HAVE_ST_BLOCKS</CODE> is to be avoided, as its
|
|
support will cease in the future.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_member_struct_stat_st_blocks</CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRUCT_TM">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
time.h sys/time.h If <TT>time.h</TT> does not
|
|
define <CODE>struct tm</CODE>, define
|
|
<CODE>TM_IN_SYS_TIME</CODE>, which means that
|
|
including <TT>sys/time.h</TT> had better define
|
|
<CODE>struct tm</CODE>.</P><P>
|
|
|
|
This macro is obsolescent, as <TT>time.h</TT>
|
|
defines <CODE>struct tm</CODE> in current systems.
|
|
New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRUCT_TIMEZONE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Figure out how to get the current timezone. If
|
|
<CODE>struct tm</CODE> has a
|
|
<CODE>tm_zone</CODE> member, define
|
|
<CODE>HAVE_STRUCT_TM_TM_ZONE</CODE> (and the
|
|
obsoleted <CODE>HAVE_TM_ZONE</CODE>). Otherwise, if
|
|
the external array <CODE>tzname</CODE> is found,
|
|
define <CODE>HAVE_TZNAME</CODE>; if it is declared,
|
|
define <CODE>HAVE_DECL_TZNAME</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_MEMBER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
action-if-found, action-if-not-found, @ includes,
|
|
AC_INCLUDES_DEFAULT) Check whether
|
|
<VAR>member</VAR> is a member of the aggregate
|
|
<VAR>aggregate</VAR>. If no
|
|
<VAR>includes</VAR> are specified, the default
|
|
includes are used (Default Includes).</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_MEMBER([struct
|
|
passwd.pw_gecos], [], [AC_MSG_ERROR([we need
|
|
`passwd.pw_gecos'])], [[#include
|
|
<pwd.h>]])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You can use this macro for submembers:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_MEMBER(struct
|
|
top.middle.bot) </pre></td></tr></table></P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>av_cv_member_<VAR>aggregate</VAR>_<VAR>member</VAR></CODE>
|
|
variable, with characters not suitable for a variable name
|
|
mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_MEMBERS">
|
|
<prototype>
|
|
<parameter content="members"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
<parameter content="[includes= AC_INCLUDES_DEFAULT]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Check for the existence of each
|
|
<samp><VAR>aggregate</VAR>.<VAR>member</VAR></samp>
|
|
of <VAR>members</VAR> using the previous macro.
|
|
When <VAR>member</VAR> belongs to
|
|
<VAR>aggregate</VAR>, define
|
|
<CODE>HAVE_<VAR>aggregate</VAR>_<VAR>member</VAR></CODE>
|
|
(in all capitals, with spaces and dots replaced by underscores).
|
|
If <VAR>action-if-found</VAR> is given, it is
|
|
executed for each of the found members. If
|
|
<VAR>action-if-not-found</VAR> is given, it is
|
|
executed for each of the members that could not be found.</P><P>
|
|
|
|
<VAR>includes</VAR> is a series of include
|
|
directives, defaulting to
|
|
<CODE>AC_INCLUDES_DEFAULT</CODE> (Default Includes),
|
|
which are used prior to the members under test.</P><P>
|
|
|
|
This macro uses M4 lists:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_MEMBERS([struct
|
|
stat.st_rdev, struct stat.st_blksize])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_GETGROUPS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>GETGROUPS_T</CODE> to be whichever
|
|
of <CODE>gid_t</CODE> or
|
|
<CODE>int</CODE> is the base type of the array
|
|
argument to <CODE>getgroups</CODE>.</P><P>
|
|
|
|
This macro caches the base type in the
|
|
<CODE>ac_cv_type_getgroups</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_INT8_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <TT>stdint.h</TT> or
|
|
<TT>inttypes.h</TT> does not define the type
|
|
<CODE>int8_t</CODE>, define
|
|
<CODE>int8_t</CODE> to a signed integer type that is
|
|
exactly 8 bits wide and that uses two's complement
|
|
representation, if such a type exists. If you are worried about
|
|
porting to hosts that lack such a type, you can use the results
|
|
of this macro in C89-or-later code as follows:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #if HAVE_STDINT_H # include
|
|
<stdint.h> #endif #if defined INT8_MAX || defined int8_t
|
|
<EM>code using int8_t</EM> #else
|
|
<EM>complicated alternative using >8-bit 'signed
|
|
char'</EM> #endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro caches the type in the
|
|
<CODE>ac_cv_c_int8_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_INT16_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This is like <CODE>AC_TYPE_INT8_T</CODE>, except
|
|
for 16-bit integers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_INT32_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This is like <CODE>AC_TYPE_INT8_T</CODE>, except
|
|
for 32-bit integers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_INT64_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This is like <CODE>AC_TYPE_INT8_T</CODE>, except
|
|
for 64-bit integers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_INTMAX_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <TT>stdint.h</TT> or
|
|
<TT>inttypes.h</TT> defines the type
|
|
<CODE>intmax_t</CODE>, define
|
|
<CODE>HAVE_INTMAX_T</CODE>. Otherwise, define
|
|
<CODE>intmax_t</CODE> to the widest signed integer
|
|
type.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_INTPTR_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <TT>stdint.h</TT> or
|
|
<TT>inttypes.h</TT> defines the type
|
|
<CODE>intptr_t</CODE>, define
|
|
<CODE>HAVE_INTPTR_T</CODE>. Otherwise, define
|
|
<CODE>intptr_t</CODE> to a signed integer type wide
|
|
enough to hold a pointer, if such a type exists.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_LONG_DOUBLE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports a working <CODE>long
|
|
double</CODE> type, define
|
|
<CODE>HAVE_LONG_DOUBLE</CODE>. The <CODE>long
|
|
double</CODE> type might have the same range and precision
|
|
as <CODE>double</CODE>.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_long_double</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current C compilers support
|
|
<CODE>long double</CODE>. New programs need not use
|
|
this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_LONG_DOUBLE_WIDER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports a working <CODE>long
|
|
double</CODE> type with more range or precision than the
|
|
<CODE>double</CODE> type, define
|
|
<CODE>HAVE_LONG_DOUBLE_WIDER</CODE>.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_long_double_wider</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_LONG_LONG_INT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports a working <CODE>long long
|
|
int</CODE> type, define
|
|
<CODE>HAVE_LONG_LONG_INT</CODE>. However, this test
|
|
does not test <CODE>long long int</CODE> values in
|
|
preprocessor <CODE>#if</CODE> expressions, because
|
|
too many compilers mishandle such expressions. .</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_long_long_int</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_MBSTATE_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
wchar.h Define <CODE>HAVE_MBSTATE_T</CODE> if
|
|
<CODE><wchar.h></CODE> declares the
|
|
<CODE>mbstate_t</CODE> type. Also, define
|
|
<CODE>mbstate_t</CODE> to be a type if
|
|
<CODE><wchar.h></CODE> does not declare it.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_mbstate_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_MODE_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>mode_t</CODE> to a suitable type, if
|
|
standard headers do not define it.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_mode_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_OFF_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>off_t</CODE> to a suitable type, if
|
|
standard headers do not define it.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_off_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_PID_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>pid_t</CODE> to a suitable type, if
|
|
standard headers do not define it.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_pid_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_SIZE_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>size_t</CODE> to a suitable type, if
|
|
standard headers do not define it.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_size_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_SSIZE_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>ssize_t</CODE> to a suitable type,
|
|
if standard headers do not define it.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_ssize_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UID_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>uid_t</CODE> and
|
|
<CODE>gid_t</CODE> to suitable types, if standard
|
|
headers do not define them.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_uid_t</CODE> variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UINT8_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <TT>stdint.h</TT> or
|
|
<TT>inttypes.h</TT> does not define the type
|
|
<CODE>uint8_t</CODE>, define
|
|
<CODE>uint8_t</CODE> to an unsigned integer type
|
|
that is exactly 8 bits wide, if such a type exists. This is like
|
|
<CODE>AC_TYPE_INT8_T</CODE>, except for unsigned
|
|
integers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UINT16_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This is like <CODE>AC_TYPE_UINT8_T</CODE>,
|
|
except for 16-bit integers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UINT32_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This is like <CODE>AC_TYPE_UINT8_T</CODE>,
|
|
except for 32-bit integers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UINT64_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This is like <CODE>AC_TYPE_UINT8_T</CODE>,
|
|
except for 64-bit integers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UINTMAX_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <TT>stdint.h</TT> or
|
|
<TT>inttypes.h</TT> defines the type
|
|
<CODE>uintmax_t</CODE>, define
|
|
<CODE>HAVE_UINTMAX_T</CODE>. Otherwise, define
|
|
<CODE>uintmax_t</CODE> to the widest unsigned
|
|
integer type.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UINTPTR_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <TT>stdint.h</TT> or
|
|
<TT>inttypes.h</TT> defines the type
|
|
<CODE>uintptr_t</CODE>, define
|
|
<CODE>HAVE_UINTPTR_T</CODE>. Otherwise, define
|
|
<CODE>uintptr_t</CODE> to an unsigned integer type
|
|
wide enough to hold a pointer, if such a type exists.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_UNSIGNED_LONG_LONG_INT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports a working <CODE>unsigned
|
|
long long int</CODE> type, define
|
|
<CODE>HAVE_UNSIGNED_LONG_LONG_INT</CODE>. However,
|
|
this test does not test <CODE>unsigned long long
|
|
int</CODE> values in preprocessor
|
|
<CODE>#if</CODE> expressions, because too many
|
|
compilers mishandle such expressions. .</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_unsigned_long_long_int</CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_TYPE">
|
|
<prototype>
|
|
<parameter content="type"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
<parameter content="[includes= AC_INCLUDES_DEFAULT]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Check whether <VAR>type</VAR> is defined. It may
|
|
be a compiler builtin type or defined by the
|
|
<VAR>includes</VAR>.
|
|
<VAR>includes</VAR> is a series of include
|
|
directives, defaulting to
|
|
<CODE>AC_INCLUDES_DEFAULT</CODE> (Default Includes),
|
|
which are used prior to the type under test.</P><P>
|
|
|
|
In C, <VAR>type</VAR> must be a type-name, so that
|
|
the expression <samp>sizeof
|
|
(<VAR>type</VAR>)</samp> is valid (but
|
|
<samp>sizeof ((<VAR>type</VAR>))</samp>
|
|
is not). The same test is applied when compiling for C++, which
|
|
means that in C++ <VAR>type</VAR> should be a
|
|
type-id and should not be an anonymous
|
|
<samp>struct</samp> or
|
|
<samp>union</samp>.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_type_<VAR>type</VAR></CODE>
|
|
variable, with <samp>*</samp> mapped to
|
|
<samp>p</samp> and other characters not suitable for
|
|
a variable name mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_TYPES">
|
|
<prototype>
|
|
<parameter content="types"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
<parameter content="[includes= AC_INCLUDES_DEFAULT]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each <VAR>type</VAR> of the
|
|
<VAR>types</VAR> that is defined, define
|
|
<CODE>HAVE_<VAR>type</VAR></CODE> (in
|
|
all capitals). Each <VAR>type</VAR> must follow the
|
|
rules of <CODE>AC_CHECK_TYPE</CODE>. If no
|
|
<VAR>includes</VAR> are specified, the default
|
|
includes are used (Default Includes). If
|
|
<VAR>action-if-found</VAR> is given, it is
|
|
additional shell code to execute when one of the types is found.
|
|
If <VAR>action-if-not-found</VAR> is given, it is
|
|
executed when one of the types is not found.</P><P>
|
|
|
|
This macro uses M4 lists:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_TYPES([ptrdiff_t])
|
|
AC_CHECK_TYPES([unsigned long long int, uintmax_t])
|
|
AC_CHECK_TYPES([float_t], [], [], [[#include <math.h>]])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_SIZEOF">
|
|
<prototype>
|
|
<parameter content="type-or-expr"/>
|
|
<parameter content="[unused]"/>
|
|
<parameter content="@ [includes= AC_INCLUDES_DEFAULT]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
-or-expr} -or-expr} Define
|
|
<CODE>SIZEOF_<VAR>type-or-expr</VAR></CODE>
|
|
(Standard Symbols) to be the size in bytes of
|
|
<VAR>type-or-expr</VAR>, which may be either a type
|
|
or an expression returning a value that has a size. If the
|
|
expression <samp>sizeof
|
|
(<VAR>type-or-expr</VAR>)</samp> is invalid,
|
|
the result is 0. <VAR>includes</VAR> is a series of
|
|
include directives, defaulting to
|
|
<CODE>AC_INCLUDES_DEFAULT</CODE> (Default Includes),
|
|
which are used prior to the expression under test.</P><P>
|
|
|
|
This macro now works even when cross-compiling. The
|
|
<VAR>unused</VAR> argument was used when
|
|
cross-compiling.</P><P>
|
|
|
|
For example, the call</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_SIZEOF([int *])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
defines <CODE>SIZEOF_INT_P</CODE> to be 8 on DEC
|
|
Alpha AXP systems.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_sizeof_<VAR>type-or-expr</VAR></CODE>
|
|
variable, with <samp>*</samp> mapped to
|
|
<samp>p</samp> and other characters not suitable for
|
|
a variable name mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECK_ALIGNOF">
|
|
<prototype>
|
|
<parameter content="type"/>
|
|
<parameter content="[includes= AC_INCLUDES_DEFAULT]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
-or-expr} Define
|
|
<CODE>ALIGNOF_<VAR>type</VAR></CODE>
|
|
(Standard Symbols) to be the alignment in bytes of
|
|
<VAR>type</VAR>.
|
|
<samp><VAR>type</VAR> y;</samp> must be
|
|
valid as a structure member declaration. If
|
|
<samp>type</samp> is unknown, the result is 0. If
|
|
no <VAR>includes</VAR> are specified, the default
|
|
includes are used (Default Includes).</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_alignof_<VAR>type-or-expr</VAR></CODE>
|
|
variable, with <samp>*</samp> mapped to
|
|
<samp>p</samp> and other characters not suitable for
|
|
a variable name mapped to underscores.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_COMPUTE_INT">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="expression"/>
|
|
<parameter content="@ [includes= AC_INCLUDES_DEFAULT]"/>
|
|
<parameter content="[action-if-fails]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Store into the shell variable <VAR>var</VAR> the
|
|
value of the integer <VAR>expression</VAR>. The
|
|
value should fit in an initializer in a C variable of type
|
|
<CODE>signed long</CODE>. To support cross
|
|
compilation (in which case, the macro only works on hosts that
|
|
use twos-complement arithmetic), it should be possible to
|
|
evaluate the expression at compile-time. If no
|
|
<VAR>includes</VAR> are specified, the default
|
|
includes are used (Default Includes).</P><P>
|
|
|
|
Execute <VAR>action-if-fails</VAR> if the value
|
|
cannot be determined correctly.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_WERROR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Normally Autoconf ignores warnings generated by the compiler,
|
|
linker, and preprocessor. If this macro is used, warnings count
|
|
as fatal errors for the current language. This macro is useful
|
|
when the results of configuration are used where warnings are
|
|
unacceptable; for instance, if parts of a program are built with
|
|
the GCC <samp>-Werror</samp> option. If the whole
|
|
program is built using <samp>-Werror</samp> it is
|
|
often simpler to put <samp>-Werror</samp> in the
|
|
compiler flags (<CODE>CFLAGS</CODE>, etc.).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_OPENMP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
http://@/www.openmp.org/, OpenMP specifies extensions of
|
|
C, C++, and Fortran that simplify optimization of shared memory
|
|
parallelism, which is a common problem on multicore CPUs.</P><P>
|
|
|
|
If the current language is C, the macro
|
|
<CODE>AC_OPENMP</CODE> sets the variable
|
|
<CODE>OPENMP_CFLAGS</CODE> to the C compiler flags
|
|
needed for supporting OpenMP@.
|
|
<CODE>OPENMP_CFLAGS</CODE> is set to empty if the
|
|
compiler already supports OpenMP, if it has no way to activate
|
|
OpenMP support, or if the user rejects OpenMP support by
|
|
invoking <samp>configure</samp> with the
|
|
<samp>--disable-openmp</samp> option.</P><P>
|
|
|
|
<CODE>OPENMP_CFLAGS</CODE> needs to be used when
|
|
compiling programs, when preprocessing program source, and when
|
|
linking programs. Therefore you need to add
|
|
<CODE>$(OPENMP_CFLAGS)</CODE> to the
|
|
<CODE>CFLAGS</CODE> of C programs that use OpenMP@.
|
|
If you preprocess OpenMP-specific C code, you also need to add
|
|
<CODE>$(OPENMP_CFLAGS)</CODE> to
|
|
<CODE>CPPFLAGS</CODE>. The presence of OpenMP
|
|
support is revealed at compile time by the preprocessor macro
|
|
<CODE>_OPENMP</CODE>.</P><P>
|
|
|
|
Linking a program with <CODE>OPENMP_CFLAGS</CODE>
|
|
typically adds one more shared library to the program's
|
|
dependencies, so its use is recommended only on programs that
|
|
actually require OpenMP.</P><P>
|
|
|
|
If the current language is C++,
|
|
<CODE>AC_OPENMP</CODE> sets the variable
|
|
<CODE>OPENMP_CXXFLAGS</CODE>, suitably for the C++
|
|
compiler. The same remarks hold as for C.</P><P>
|
|
|
|
If the current language is Fortran 77 or Fortran,
|
|
<CODE>AC_OPENMP</CODE> sets the variable
|
|
<CODE>OPENMP_FFLAGS</CODE> or
|
|
<CODE>OPENMP_FCFLAGS</CODE>, respectively. Similar
|
|
remarks as for C hold, except that
|
|
<CODE>CPPFLAGS</CODE> is not used for Fortran, and
|
|
no preprocessor macro signals OpenMP support.</P><P>
|
|
|
|
For portability, it is best to avoid spaces between
|
|
<samp>#</samp> and <samp>pragma
|
|
omp</samp>. That is, write <samp>#pragma
|
|
omp</samp>, not <samp># pragma omp</samp>.
|
|
The Sun WorkShop 6.2 C compiler chokes on the latter.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CC">
|
|
<prototype>
|
|
<parameter content="[compiler-search-list]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine a C compiler to use. If
|
|
<CODE>CC</CODE> is not already set in the
|
|
environment, check for <CODE>gcc</CODE> and
|
|
<CODE>cc</CODE>, then for other C compilers. Set
|
|
output variable <CODE>CC</CODE> to the name of the
|
|
compiler found.</P><P>
|
|
|
|
This macro may, however, be invoked with an optional first
|
|
argument which, if specified, must be a blank-separated list of
|
|
C compilers to search for. This just gives the user an
|
|
opportunity to specify an alternative search list for the C
|
|
compiler. For example, if you didn't like the default order,
|
|
then you could invoke <CODE>AC_PROG_CC</CODE> like
|
|
this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PROG_CC([gcc cl cc])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If the C compiler does not handle function prototypes correctly
|
|
by default, try to add an option to output variable
|
|
<CODE>CC</CODE> to make it so. This macro tries
|
|
various options that select standard-conformance modes on
|
|
various systems.</P><P>
|
|
|
|
After calling this macro you can check whether the C compiler
|
|
has been set to accept ANSI C89 (ISO C90); if not, the shell
|
|
variable <CODE>ac_cv_prog_cc_c89</CODE> is set to
|
|
<samp>no</samp>. See also
|
|
<CODE>AC_C_PROTOTYPES</CODE> below.</P><P>
|
|
|
|
If using the GNU C compiler, set shell variable
|
|
<CODE>GCC</CODE> to <samp>yes</samp>.
|
|
If output variable <CODE>CFLAGS</CODE> was not
|
|
already set, set it to <samp>-g -O2</samp> for the
|
|
GNU C compiler (<samp>-O2</samp> on systems where
|
|
GCC does not accept <samp>-g</samp>), or
|
|
<samp>-g</samp> for other compilers. If your
|
|
package does not like this default, then it is acceptable to
|
|
insert the line <samp>: $CFLAGS=""@</samp> after
|
|
<CODE>AC_INIT</CODE> and before
|
|
<CODE>AC_PROG_CC</CODE> to select an empty default
|
|
instead.</P><P>
|
|
|
|
Many Autoconf macros use a compiler, and thus call
|
|
<samp>AC_REQUIRE([AC_PROG_CC])</samp> to ensure that
|
|
the compiler has been determined before the body of the
|
|
outermost <CODE>AC_DEFUN</CODE> macro. Although
|
|
<CODE>AC_PROG_CC</CODE> is safe to directly expand
|
|
multiple times, it performs certain checks (such as the proper
|
|
value of EXEEXT) only on the first invocation. Therefore, care
|
|
must be used when invoking this macro from within another macro
|
|
rather than at the top level (Expanded Before Required).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CC_C_O">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler does not accept the
|
|
<samp>-c</samp> and <samp>-o</samp>
|
|
options simultaneously, define
|
|
<CODE>NO_MINUS_C_MINUS_O</CODE>. This macro
|
|
actually tests both the compiler found by
|
|
<CODE>AC_PROG_CC</CODE>, and, if different, the
|
|
first <CODE>cc</CODE> in the path. The test fails
|
|
if one fails. This macro was created for GNU Make to choose the
|
|
default C compilation rule.</P><P>
|
|
|
|
For the compiler <VAR>compiler</VAR>, this macro
|
|
caches its result in the
|
|
<CODE>ac_cv_prog_cc_<VAR>compiler</VAR>_c_o</CODE>
|
|
variable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CPP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>CPP</CODE> to a command
|
|
that runs the C preprocessor. If <samp>$CC
|
|
-E</samp> doesn't work, <TT>/lib/cpp</TT> is
|
|
used. It is only portable to run <CODE>CPP</CODE> on
|
|
files with a <TT>.c</TT> extension.</P><P>
|
|
|
|
Some preprocessors don't indicate missing include files by the
|
|
error status. For such preprocessors an internal variable is
|
|
set that causes other macros to check the standard error from
|
|
the preprocessor and consider the test failed if any warnings
|
|
have been reported. For most preprocessors, though, warnings do
|
|
not cause include-file tests to fail unless
|
|
<CODE>AC_PROG_CPP_WERROR</CODE> is also specified.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CPP_WERROR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This acts like <CODE>AC_PROG_CPP</CODE>, except it
|
|
treats warnings from the preprocessor as errors even if the
|
|
preprocessor exit status indicates success. This is useful for
|
|
avoiding headers that generate mandatory warnings, such as
|
|
deprecation notices.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CC_STDC">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler cannot compile ISO Standard C (currently
|
|
C99), try to add an option to output variable
|
|
<CODE>CC</CODE> to make it work. If the compiler
|
|
does not support C99, fall back to supporting ANSI C89 (ISO
|
|
C90).</P><P>
|
|
|
|
After calling this macro you can check whether the C compiler
|
|
has been set to accept Standard C; if not, the shell variable
|
|
<CODE>ac_cv_prog_cc_stdc</CODE> is set to
|
|
<samp>no</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CC_C89">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler is not in ANSI C89 (ISO C90) mode by
|
|
default, try to add an option to output variable
|
|
<CODE>CC</CODE> to make it so. This macro tries
|
|
various options that select ANSI C89 on some system or another,
|
|
preferring extended functionality modes over strict conformance
|
|
modes. It considers the compiler to be in ANSI C89 mode if it
|
|
handles function prototypes correctly.</P><P>
|
|
|
|
After calling this macro you can check whether the C compiler
|
|
has been set to accept ANSI C89; if not, the shell variable
|
|
<CODE>ac_cv_prog_cc_c89</CODE> is set to
|
|
<samp>no</samp>.</P><P>
|
|
|
|
This macro is called automatically by
|
|
<CODE>AC_PROG_CC</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CC_C99">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler is not in C99 mode by default, try to add an
|
|
option to output variable <CODE>CC</CODE> to make it
|
|
so. This macro tries various options that select C99 on some
|
|
system or another, preferring extended functionality modes over
|
|
strict conformance modes. It considers the compiler to be in
|
|
C99 mode if it handles <CODE>_Bool</CODE>,
|
|
<CODE>//</CODE> comments, flexible array members,
|
|
<CODE>inline</CODE>, signed and unsigned
|
|
<CODE>long long int</CODE>, mixed code and
|
|
declarations, named initialization of structs,
|
|
<CODE>restrict</CODE>,
|
|
<CODE>va_copy</CODE>, varargs macros, variable
|
|
declarations in <CODE>for</CODE> loops, and variable
|
|
length arrays.</P><P>
|
|
|
|
After calling this macro you can check whether the C compiler
|
|
has been set to accept C99; if not, the shell variable
|
|
<CODE>ac_cv_prog_cc_c99</CODE> is set to
|
|
<samp>no</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_BACKSLASH_A">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <samp>HAVE_C_BACKSLASH_A</samp> to 1 if the
|
|
C compiler understands <samp>\a</samp>.</P><P>
|
|
|
|
This macro is obsolescent, as current C compilers understand
|
|
<samp>\a</samp>. New programs need not use this
|
|
macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_BIGENDIAN">
|
|
<prototype>
|
|
<parameter content="[action-if-true]"/>
|
|
<parameter content="[action-if-false]"/>
|
|
<parameter content="@ [action-if-unknown]"/>
|
|
<parameter content="[action-if-universal]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If words are stored with the most significant byte first
|
|
(like Motorola and SPARC CPUs), execute
|
|
<VAR>action-if-true</VAR>. If words are stored with
|
|
the least significant byte first (like Intel and VAX CPUs),
|
|
execute <VAR>action-if-false</VAR>.</P><P>
|
|
|
|
This macro runs a test-case if endianness cannot be determined
|
|
from the system header files. When cross-compiling, the
|
|
test-case is not run but grep'ed for some magic values.
|
|
<VAR>action-if-unknown</VAR> is executed if the
|
|
latter case fails to determine the byte sex of the host system.</P><P>
|
|
|
|
In some cases a single run of a compiler can generate code for
|
|
multiple architectures. This can happen, for example, when
|
|
generating Mac OS X universal binary files, which work on both
|
|
PowerPC and Intel architectures. In this case, the different
|
|
variants might be for different architectures whose endiannesses
|
|
differ. If <CODE>configure</CODE> detects this, it
|
|
executes <VAR>action-if-universal</VAR> instead of
|
|
<VAR>action-if-unknown</VAR>.</P><P>
|
|
|
|
The default for <VAR>action-if-true</VAR> is to
|
|
define <samp>WORDS_BIGENDIAN</samp>. The default
|
|
for <VAR>action-if-false</VAR> is to do nothing.
|
|
The default for <VAR>action-if-unknown</VAR> is to
|
|
abort configure and tell the installer how to bypass this test.
|
|
And finally, the default for
|
|
<VAR>action-if-universal</VAR> is to ensure that
|
|
<samp>WORDS_BIGENDIAN</samp> is defined if and only
|
|
if a universal build is detected and the current code is
|
|
big-endian; this default works only if
|
|
<CODE>autoheader</CODE> is used (autoheader
|
|
Invocation).</P><P>
|
|
|
|
If you use this macro without specifying
|
|
<VAR>action-if-universal</VAR>, you should also use
|
|
<CODE>AC_CONFIG_HEADERS</CODE>; otherwise
|
|
<samp>WORDS_BIGENDIAN</samp> may be set incorrectly
|
|
for Mac OS X universal binary files.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_CONST">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler does not fully support the
|
|
<CODE>const</CODE> keyword, define
|
|
<CODE>const</CODE> to be empty. Some C compilers
|
|
that do not define <CODE>__STDC__</CODE> do support
|
|
<CODE>const</CODE>; some compilers that define
|
|
<CODE>__STDC__</CODE> do not completely support
|
|
<CODE>const</CODE>. Programs can simply use
|
|
<CODE>const</CODE> as if every C compiler supported
|
|
it; for those that don't, the makefile or configuration header
|
|
file defines it as empty.</P><P>
|
|
|
|
Occasionally installers use a C++ compiler to compile C code,
|
|
typically because they lack a C compiler. This causes problems
|
|
with <CODE>const</CODE>, because C and C++ treat
|
|
<CODE>const</CODE> differently. For example:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> const int foo;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is valid in C but not in C++. These differences unfortunately
|
|
cannot be papered over by defining
|
|
<CODE>const</CODE> to be empty.</P><P>
|
|
|
|
If <CODE>autoconf</CODE> detects this situation, it
|
|
leaves <CODE>const</CODE> alone, as this generally
|
|
yields better results in practice. However, using a C++
|
|
compiler to compile C code is not recommended or supported, and
|
|
installers who run into trouble in this area should get a C
|
|
compiler like GCC to compile their C code.</P><P>
|
|
|
|
This macro caches its result in the
|
|
<CODE>ac_cv_c_const</CODE> variable.</P><P>
|
|
|
|
This macro is obsolescent, as current C compilers support
|
|
<CODE>const</CODE>. New programs need not use this
|
|
macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_RESTRICT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler recognizes a variant spelling for the
|
|
<CODE>restrict</CODE> keyword
|
|
(<CODE>__restrict</CODE>,
|
|
<CODE>__restrict__</CODE>, or
|
|
<CODE>_Restrict</CODE>), then define
|
|
<CODE>restrict</CODE> to that; this is more likely
|
|
to do the right thing with compilers that support language
|
|
variants where plain <CODE>restrict</CODE> is not a
|
|
keyword. Otherwise, if the C compiler recognizes the
|
|
<CODE>restrict</CODE> keyword, don't do anything.
|
|
Otherwise, define <CODE>restrict</CODE> to be empty.
|
|
Thus, programs may simply use <CODE>restrict</CODE>
|
|
as if every C compiler supported it; for those that do not, the
|
|
makefile or configuration header defines it away.</P><P>
|
|
|
|
Although support in C++ for the
|
|
<CODE>restrict</CODE> keyword is not required,
|
|
several C++ compilers do accept the keyword. This macro works
|
|
for them, too.</P><P>
|
|
|
|
This macro caches <samp>no</samp> in the
|
|
<CODE>ac_cv_c_restrict</CODE> variable if
|
|
<CODE>restrict</CODE> is not supported, and a
|
|
supported spelling otherwise.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_VOLATILE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler does not understand the keyword
|
|
<CODE>volatile</CODE>, define
|
|
<CODE>volatile</CODE> to be empty. Programs can
|
|
simply use <CODE>volatile</CODE> as if every C
|
|
compiler supported it; for those that do not, the makefile or
|
|
configuration header defines it as empty.</P><P>
|
|
|
|
If the correctness of your program depends on the semantics of
|
|
<CODE>volatile</CODE>, simply defining it to be
|
|
empty does, in a sense, break your code. However, given that
|
|
the compiler does not support <CODE>volatile</CODE>,
|
|
you are at its mercy anyway. At least your program compiles,
|
|
when it wouldn't before. , for more about
|
|
<CODE>volatile</CODE>.</P><P>
|
|
|
|
In general, the <CODE>volatile</CODE> keyword is a
|
|
standard C feature, so you might expect that
|
|
<CODE>volatile</CODE> is available only when
|
|
<CODE>__STDC__</CODE> is defined. However, Ultrix
|
|
4.3's native compiler does support volatile, but does not define
|
|
<CODE>__STDC__</CODE>.</P><P>
|
|
|
|
This macro is obsolescent, as current C compilers support
|
|
<CODE>volatile</CODE>. New programs need not use
|
|
this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_INLINE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports the keyword
|
|
<CODE>inline</CODE>, do nothing. Otherwise define
|
|
<CODE>inline</CODE> to
|
|
<CODE>__inline__</CODE> or
|
|
<CODE>__inline</CODE> if it accepts one of those,
|
|
otherwise define <CODE>inline</CODE> to be empty.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_CHAR_UNSIGNED">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C type <CODE>char</CODE> is unsigned,
|
|
define <CODE>__CHAR_UNSIGNED__</CODE>, unless the C
|
|
compiler predefines it.</P><P>
|
|
|
|
These days, using this macro is not necessary. The same
|
|
information can be determined by this portable alternative, thus
|
|
avoiding the use of preprocessor macros in the namespace
|
|
reserved for the implementation.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #include <limits.h> #if
|
|
CHAR_MIN == 0 # define CHAR_UNSIGNED 1 #endif
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_STRINGIZE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C preprocessor supports the stringizing operator,
|
|
define <CODE>HAVE_STRINGIZE</CODE>. The stringizing
|
|
operator is <samp>#</samp> and is found in macros
|
|
such as this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #define x(y) #y
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro is obsolescent, as current C compilers support the
|
|
stringizing operator. New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_FLEXIBLE_ARRAY_MEMBER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports flexible array members, define
|
|
<CODE>FLEXIBLE_ARRAY_MEMBER</CODE> to nothing;
|
|
otherwise define it to 1. That way, a declaration like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> struct s size_t n_vals;
|
|
double val[FLEXIBLE_ARRAY_MEMBER]; @;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
will let applications use the ``struct hack'' even with
|
|
compilers that do not support flexible array members. To
|
|
allocate and use such an object, you can use code like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> size_t i; size_t n =
|
|
compute_value_count (); struct s *p = malloc (offsetof
|
|
(struct s, val) + n * sizeof (double)); p->n_vals
|
|
= n; for (i = 0; i < n; i++) p->val[i] = compute_value
|
|
(i); </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_VARARRAYS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports variable-length arrays, define
|
|
<CODE>HAVE_C_VARARRAYS</CODE>. A variable-length
|
|
array is an array of automatic storage duration whose length is
|
|
determined at run time, when the array is declared.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_TYPEOF">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports GCC's
|
|
<CODE>typeof</CODE> syntax either directly or
|
|
through a different spelling of the keyword (e.g.,
|
|
<CODE>__typeof__</CODE>), define
|
|
<CODE>HAVE_TYPEOF</CODE>. If the support is
|
|
available only through a different spelling, define
|
|
<CODE>typeof</CODE> to that spelling.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_PROTOTYPES">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If function prototypes are understood by the compiler (as
|
|
determined by <CODE>AC_PROG_CC</CODE>), define
|
|
<CODE>PROTOTYPES</CODE> and
|
|
<CODE>__PROTOTYPES</CODE>. Defining
|
|
<CODE>__PROTOTYPES</CODE> is for the benefit of
|
|
header files that cannot use macros that infringe on user name
|
|
space.</P><P>
|
|
|
|
This macro is obsolescent, as current C compilers support
|
|
prototypes. New programs need not use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_GCC_TRADITIONAL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Add <samp>-traditional</samp> to output variable
|
|
<CODE>CC</CODE> if using the GNU C compiler and
|
|
<CODE>ioctl</CODE> does not work properly without
|
|
<samp>-traditional</samp>. That usually happens
|
|
when the fixed header files have not been installed on an old
|
|
system.</P><P>
|
|
|
|
This macro is obsolescent, since current versions of the GNU C
|
|
compiler fix the header files automatically when installed.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CXX">
|
|
<prototype>
|
|
<parameter content="[compiler-search-list]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine a C++ compiler to use. Check whether the
|
|
environment variable <CODE>CXX</CODE> or
|
|
<CODE>CCC</CODE> (in that order) is set; if so, then
|
|
set output variable <CODE>CXX</CODE> to its value.</P><P>
|
|
|
|
Otherwise, if the macro is invoked without an argument, then
|
|
search for a C++ compiler under the likely names (first
|
|
<CODE>g++</CODE> and <CODE>c++</CODE>
|
|
then other names). If none of those checks succeed, then as a
|
|
last resort set <CODE>CXX</CODE> to
|
|
<CODE>g++</CODE>.</P><P>
|
|
|
|
This macro may, however, be invoked with an optional first
|
|
argument which, if specified, must be a blank-separated list of
|
|
C++ compilers to search for. This just gives the user an
|
|
opportunity to specify an alternative search list for the C++
|
|
compiler. For example, if you didn't like the default order,
|
|
then you could invoke <CODE>AC_PROG_CXX</CODE> like
|
|
this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PROG_CXX([gcc cl KCC CC cxx cc++
|
|
xlC aCC c++ g++])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If using the GNU C++ compiler, set shell variable
|
|
<CODE>GXX</CODE> to <samp>yes</samp>.
|
|
If output variable <CODE>CXXFLAGS</CODE> was not
|
|
already set, set it to <samp>-g -O2</samp> for the
|
|
GNU C++ compiler (<samp>-O2</samp> on systems where
|
|
G++ does not accept <samp>-g</samp>), or
|
|
<samp>-g</samp> for other compilers. If your
|
|
package does not like this default, then it is acceptable to
|
|
insert the line <samp>: $CXXFLAGS=""@</samp> after
|
|
<CODE>AC_INIT</CODE> and before
|
|
<CODE>AC_PROG_CXX</CODE> to select an empty default
|
|
instead.</P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CXXCPP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>CXXCPP</CODE> to a
|
|
command that runs the C++ preprocessor. If <samp>$CXX
|
|
-E</samp> doesn't work, <TT>/lib/cpp</TT> is
|
|
used. It is portable to run <CODE>CXXCPP</CODE> only
|
|
on files with a <TT>.c</TT>,
|
|
<TT>.C</TT>, <TT>.cc</TT>, or
|
|
<TT>.cpp</TT> extension.</P><P>
|
|
|
|
Some preprocessors don't indicate missing include files by the
|
|
error status. For such preprocessors an internal variable is
|
|
set that causes other macros to check the standard error from
|
|
the preprocessor and consider the test failed if any warnings
|
|
have been reported. However, it is not known whether such
|
|
broken preprocessors exist for C++.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_CXX_C_O">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Test whether the C++ compiler accepts the options
|
|
<samp>-c</samp> and <samp>-o</samp>
|
|
simultaneously, and define
|
|
<CODE>CXX_NO_MINUS_C_MINUS_O</CODE>, if it does not.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_OBJC">
|
|
<prototype>
|
|
<parameter content="[compiler-search-list]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine an Objective C compiler to use. If
|
|
<CODE>OBJC</CODE> is not already set in the
|
|
environment, check for Objective C compilers. Set output
|
|
variable <CODE>OBJC</CODE> to the name of the
|
|
compiler found.</P><P>
|
|
|
|
This macro may, however, be invoked with an optional first
|
|
argument which, if specified, must be a blank-separated list of
|
|
Objective C compilers to search for. This just gives the user
|
|
an opportunity to specify an alternative search list for the
|
|
Objective C compiler. For example, if you didn't like the
|
|
default order, then you could invoke
|
|
<CODE>AC_PROG_OBJC</CODE> like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PROG_OBJC([gcc objcc objc])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If using the GNU Objective C compiler, set shell variable
|
|
<CODE>GOBJC</CODE> to <samp>yes</samp>.
|
|
If output variable <CODE>OBJCFLAGS</CODE> was not
|
|
already set, set it to <samp>-g -O2</samp> for the
|
|
GNU Objective C compiler (<samp>-O2</samp> on
|
|
systems where <CODE>gcc</CODE> does not accept
|
|
<samp>-g</samp>), or <samp>-g</samp> for
|
|
other compilers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_OBJCPP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>OBJCPP</CODE> to a
|
|
command that runs the Objective C preprocessor. If
|
|
<samp>$OBJC -E</samp> doesn't work,
|
|
<TT>/lib/cpp</TT> is used.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_OBJCXX">
|
|
<prototype>
|
|
<parameter content="[compiler-search-list]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine an Objective C++ compiler to use. If
|
|
<CODE>OBJCXX</CODE> is not already set in the
|
|
environment, check for Objective C++ compilers. Set output
|
|
variable <CODE>OBJCXX</CODE> to the name of the
|
|
compiler found.</P><P>
|
|
|
|
This macro may, however, be invoked with an optional first
|
|
argument which, if specified, must be a blank-separated list of
|
|
Objective C++ compilers to search for. This just gives the user
|
|
an opportunity to specify an alternative search list for the
|
|
Objective C++ compiler. For example, if you didn't like the
|
|
default order, then you could invoke
|
|
<CODE>AC_PROG_OBJCXX</CODE> like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PROG_OBJCXX([gcc g++ objcc++
|
|
objcxx]) </pre></td></tr></table></P><P>
|
|
|
|
If using the GNU Objective C++ compiler, set shell variable
|
|
<CODE>GOBJCXX</CODE> to
|
|
<samp>yes</samp>. If output variable
|
|
<CODE>OBJCXXFLAGS</CODE> was not already set, set it
|
|
to <samp>-g -O2</samp> for the GNU Objective C++
|
|
compiler (<samp>-O2</samp> on systems where
|
|
<CODE>gcc</CODE> does not accept
|
|
<samp>-g</samp>), or <samp>-g</samp> for
|
|
other compilers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_OBJCXXCPP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set output variable <CODE>OBJCXXCPP</CODE> to a
|
|
command that runs the Objective C++ preprocessor. If
|
|
<samp>$OBJCXX -E</samp> doesn't work,
|
|
<TT>/lib/cpp</TT> is used.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_PATH_ERLC">
|
|
<prototype>
|
|
<parameter content="[value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine an Erlang compiler to use. If
|
|
<CODE>ERLC</CODE> is not already set in the
|
|
environment, check for <CODE>erlc</CODE>. Set
|
|
output variable <CODE>ERLC</CODE> to the complete
|
|
path of the compiler command found. In addition, if
|
|
<CODE>ERLCFLAGS</CODE> is not set in the
|
|
environment, set it to an empty value.</P><P>
|
|
|
|
The two optional arguments have the same meaning as the two last
|
|
arguments of macro <CODE>AC_PROG_PATH</CODE> for
|
|
looking for the <CODE>erlc</CODE> program. For
|
|
example, to look for <CODE>erlc</CODE> only in the
|
|
<TT>/usr/lib/erlang/bin</TT> directory:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ERLANG_PATH_ERLC([not found],
|
|
[/usr/lib/erlang/bin])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_NEED_ERLC">
|
|
<prototype>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
A simplified variant of the
|
|
<CODE>AC_ERLANG_PATH_ERLC</CODE> macro, that prints
|
|
an error message and exits the
|
|
<CODE>configure</CODE> script if the
|
|
<CODE>erlc</CODE> program is not found.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_PATH_ERL">
|
|
<prototype>
|
|
<parameter content="[value-if-not-found]"/>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine an Erlang interpreter to use. If
|
|
<CODE>ERL</CODE> is not already set in the
|
|
environment, check for <CODE>erl</CODE>. Set output
|
|
variable <CODE>ERL</CODE> to the complete path of
|
|
the interpreter command found.</P><P>
|
|
|
|
The two optional arguments have the same meaning as the two last
|
|
arguments of macro <CODE>AC_PROG_PATH</CODE> for
|
|
looking for the <CODE>erl</CODE> program. For
|
|
example, to look for <CODE>erl</CODE> only in the
|
|
<TT>/usr/lib/erlang/bin</TT> directory:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ERLANG_PATH_ERL([not found],
|
|
[/usr/lib/erlang/bin])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_NEED_ERL">
|
|
<prototype>
|
|
<parameter content="[path= $PATH]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
A simplified variant of the
|
|
<CODE>AC_ERLANG_PATH_ERL</CODE> macro, that prints
|
|
an error message and exits the
|
|
<CODE>configure</CODE> script if the
|
|
<CODE>erl</CODE> program is not found.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_F77">
|
|
<prototype>
|
|
<parameter content="[compiler-search-list]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine a Fortran 77 compiler to use. If
|
|
<CODE>F77</CODE> is not already set in the
|
|
environment, then check for <CODE>g77</CODE> and
|
|
<CODE>f77</CODE>, and then some other names. Set
|
|
the output variable <CODE>F77</CODE> to the name of
|
|
the compiler found.</P><P>
|
|
|
|
This macro may, however, be invoked with an optional first
|
|
argument which, if specified, must be a blank-separated list of
|
|
Fortran 77 compilers to search for. This just gives the user an
|
|
opportunity to specify an alternative search list for the
|
|
Fortran 77 compiler. For example, if you didn't like the
|
|
default order, then you could invoke
|
|
<CODE>AC_PROG_F77</CODE> like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PROG_F77([fl32 f77 fort77 xlf
|
|
g77 f90 xlf90]) </pre></td></tr></table></P><P>
|
|
|
|
If using <CODE>g77</CODE> (the GNU Fortran 77
|
|
compiler), then set the shell variable
|
|
<CODE>G77</CODE> to <samp>yes</samp>. If
|
|
the output variable <CODE>FFLAGS</CODE> was not
|
|
already set in the environment, then set it to <samp>-g
|
|
-02</samp> for <CODE>g77</CODE> (or
|
|
<samp>-O2</samp> where <CODE>g77</CODE>
|
|
does not accept <samp>-g</samp>). Otherwise, set
|
|
<CODE>FFLAGS</CODE> to <samp>-g</samp>
|
|
for all other Fortran 77 compilers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_FC">
|
|
<prototype>
|
|
<parameter content="[compiler-search-list]"/>
|
|
<parameter content="[dialect]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine a Fortran compiler to use. If
|
|
<CODE>FC</CODE> is not already set in the
|
|
environment, then <CODE>dialect</CODE> is a hint to
|
|
indicate what Fortran dialect to search for; the default is to
|
|
search for the newest available dialect. Set the output
|
|
variable <CODE>FC</CODE> to the name of the compiler
|
|
found.</P><P>
|
|
|
|
By default, newer dialects are preferred over older dialects,
|
|
but if <CODE>dialect</CODE> is specified then older
|
|
dialects are preferred starting with the specified dialect.
|
|
<CODE>dialect</CODE> can currently be one of Fortran
|
|
77, Fortran 90, or Fortran 95. However, this is only a hint of
|
|
which compiler <EM>name</EM> to prefer (e.g.,
|
|
<CODE>f90</CODE> or <CODE>f95</CODE>),
|
|
and no attempt is made to guarantee that a particular language
|
|
standard is actually supported. Thus, it is preferable that you
|
|
avoid the <CODE>dialect</CODE> option, and use
|
|
AC_PROG_FC only for code compatible with the latest Fortran
|
|
standard.</P><P>
|
|
|
|
This macro may, alternatively, be invoked with an optional first
|
|
argument which, if specified, must be a blank-separated list of
|
|
Fortran compilers to search for, just as in
|
|
<CODE>AC_PROG_F77</CODE>.</P><P>
|
|
|
|
If the output variable <CODE>FCFLAGS</CODE> was not
|
|
already set in the environment, then set it to <samp>-g
|
|
-02</samp> for GNU <CODE>g77</CODE> (or
|
|
<samp>-O2</samp> where <CODE>g77</CODE>
|
|
does not accept <samp>-g</samp>). Otherwise, set
|
|
<CODE>FCFLAGS</CODE> to <samp>-g</samp>
|
|
for all other Fortran compilers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROG_F77_C_O">
|
|
<prototype>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Test whether the Fortran compiler accepts the options
|
|
<samp>-c</samp> and <samp>-o</samp>
|
|
simultaneously, and define
|
|
<CODE>F77_NO_MINUS_C_MINUS_O</CODE> or
|
|
<CODE>FC_NO_MINUS_C_MINUS_O</CODE>, respectively, if
|
|
it does not.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_F77_LIBRARY_LDFLAGS">
|
|
<prototype>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine the linker flags (e.g.,
|
|
<samp>-L</samp> and <samp>-l</samp>) for
|
|
the Fortran intrinsic and runtime libraries that are required to
|
|
successfully link a Fortran program or shared library. The
|
|
output variable <CODE>FLIBS</CODE> or
|
|
<CODE>FCLIBS</CODE> is set to these flags (which
|
|
should be included after <CODE>LIBS</CODE> when
|
|
linking).</P><P>
|
|
|
|
This macro is intended to be used in those situations when it is
|
|
necessary to mix, e.g., C++ and Fortran source code in a single
|
|
program or shared library (Mixing Fortran 77 With C and C++, , ,
|
|
automake, GNU Automake).</P><P>
|
|
|
|
For example, if object files from a C++ and Fortran compiler
|
|
must be linked together, then the C++ compiler/linker must be
|
|
used for linking (since special C++-ish things need to happen at
|
|
link time like calling global constructors, instantiating
|
|
templates, enabling exception support, etc.).</P><P>
|
|
|
|
However, the Fortran intrinsic and runtime libraries must be
|
|
linked in as well, but the C++ compiler/linker doesn't know by
|
|
default how to add these Fortran 77 libraries. Hence, this
|
|
macro was created to determine these Fortran libraries.</P><P>
|
|
|
|
The macros <CODE>AC_F77_DUMMY_MAIN</CODE> and
|
|
<CODE>AC_FC_DUMMY_MAIN</CODE> or
|
|
<CODE>AC_F77_MAIN</CODE> and
|
|
<CODE>AC_FC_MAIN</CODE> are probably also necessary
|
|
to link C/C++ with Fortran; see below. Further, it is highly
|
|
recommended that you use
|
|
<CODE>AC_CONFIG_HEADERS</CODE> (Configuration
|
|
Headers) because the complex defines that the function wrapper
|
|
macros create may not work with C/C++ compiler drivers.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_F77_DUMMY_MAIN">
|
|
<prototype>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="[action-if-not-found]"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="[action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
With many compilers, the Fortran libraries detected by
|
|
<CODE>AC_F77_LIBRARY_LDFLAGS</CODE> or
|
|
<CODE>AC_FC_LIBRARY_LDFLAGS</CODE> provide their own
|
|
<CODE>main</CODE> entry function that initializes
|
|
things like Fortran I/O, and which then calls a user-provided
|
|
entry function named (say) <CODE>MAIN__</CODE> to
|
|
run the user's program. The
|
|
<CODE>AC_F77_DUMMY_MAIN</CODE> and
|
|
<CODE>AC_FC_DUMMY_MAIN</CODE> or
|
|
<CODE>AC_F77_MAIN</CODE> and
|
|
<CODE>AC_FC_MAIN</CODE> macros figure out how to
|
|
deal with this interaction.</P><P>
|
|
|
|
When using Fortran for purely numerical functions (no I/O,
|
|
etc.)@: often one prefers to provide one's own
|
|
<CODE>main</CODE> and skip the Fortran library
|
|
initializations. In this case, however, one may still need to
|
|
provide a dummy <CODE>MAIN__</CODE> routine in order
|
|
to prevent linking errors on some systems.
|
|
<CODE>AC_F77_DUMMY_MAIN</CODE> or
|
|
<CODE>AC_FC_DUMMY_MAIN</CODE> detects whether any
|
|
such routine is <EM>required</EM> for linking, and
|
|
what its name is; the shell variable
|
|
<CODE>F77_DUMMY_MAIN</CODE> or
|
|
<CODE>FC_DUMMY_MAIN</CODE> holds this name,
|
|
<CODE>unknown</CODE> when no solution was found, and
|
|
<CODE>none</CODE> when no such dummy main is needed.</P><P>
|
|
|
|
By default, <VAR>action-if-found</VAR> defines
|
|
<CODE>F77_DUMMY_MAIN</CODE> or
|
|
<CODE>FC_DUMMY_MAIN</CODE> to the name of this
|
|
routine (e.g., <CODE>MAIN__</CODE>)
|
|
<EM>if</EM> it is required.
|
|
<VAR>action-if-not-found</VAR> defaults to exiting
|
|
with an error.</P><P>
|
|
|
|
In order to link with Fortran routines, the user's C/C++ program
|
|
should then include the following code to define the dummy main
|
|
if it is needed:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #ifdef F77_DUMMY_MAIN # ifdef
|
|
__cplusplus extern "C" # endif int F77_DUMMY_MAIN ()
|
|
return 1; @ #endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
(Replace <CODE>F77</CODE> with
|
|
<CODE>FC</CODE> for Fortran instead of Fortran 77.)</P><P>
|
|
|
|
Note that this macro is called automatically from
|
|
<CODE>AC_F77_WRAPPERS</CODE> or
|
|
<CODE>AC_FC_WRAPPERS</CODE>; there is generally no
|
|
need to call it explicitly unless one wants to change the
|
|
default actions.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_F77_MAIN">
|
|
<prototype>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
As discussed above, many Fortran libraries allow you to
|
|
provide an entry point called (say)
|
|
<CODE>MAIN__</CODE> instead of the usual
|
|
<CODE>main</CODE>, which is then called by a
|
|
<CODE>main</CODE> function in the Fortran libraries
|
|
that initializes things like Fortran I/O@. The
|
|
<CODE>AC_F77_MAIN</CODE> and
|
|
<CODE>AC_FC_MAIN</CODE> macros detect whether it is
|
|
<EM>possible</EM> to utilize such an alternate main
|
|
function, and defines <CODE>F77_MAIN</CODE> and
|
|
<CODE>FC_MAIN</CODE> to the name of the function.
|
|
(If no alternate main function name is found,
|
|
<CODE>F77_MAIN</CODE> and
|
|
<CODE>FC_MAIN</CODE> are simply defined to
|
|
<CODE>main</CODE>.)</P><P>
|
|
|
|
Thus, when calling Fortran routines from C that perform things
|
|
like I/O, one should use this macro and declare the "main"
|
|
function like so:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #ifdef __cplusplus extern "C"
|
|
#endif int F77_MAIN (int argc, char *argv[]);
|
|
</pre></td></tr></table></P><P>
|
|
|
|
(Again, replace <CODE>F77</CODE> with
|
|
<CODE>FC</CODE> for Fortran instead of Fortran 77.)
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_F77_WRAPPERS">
|
|
<prototype>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Defines C macros <CODE>F77_FUNC (name,
|
|
NAME)</CODE>, <CODE>FC_FUNC (name,
|
|
NAME)</CODE>, <CODE>F77_FUNC_(name,
|
|
NAME)</CODE>, and <CODE>FC_FUNC_(name,
|
|
NAME)</CODE> to properly mangle the names of C/C++
|
|
identifiers, and identifiers with underscores, respectively, so
|
|
that they match the name-mangling scheme used by the Fortran
|
|
compiler.</P><P>
|
|
|
|
Fortran is case-insensitive, and in order to achieve this the
|
|
Fortran compiler converts all identifiers into a canonical case
|
|
and format. To call a Fortran subroutine from C or to write a C
|
|
function that is callable from Fortran, the C program must
|
|
explicitly use identifiers in the format expected by the Fortran
|
|
compiler. In order to do this, one simply wraps all C
|
|
identifiers in one of the macros provided by
|
|
<CODE>AC_F77_WRAPPERS</CODE> or
|
|
<CODE>AC_FC_WRAPPERS</CODE>. For example, suppose
|
|
you have the following Fortran 77 subroutine:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> subroutine foobar (x, y)
|
|
double precision x, y y = 3.14159 * x return
|
|
end </pre></td></tr></table></P><P>
|
|
|
|
You would then declare its prototype in C or C++ as:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> #define FOOBAR_F77 F77_FUNC
|
|
(foobar, FOOBAR) #ifdef __cplusplus extern "C" /* prevent C++
|
|
name mangling */ #endif void FOOBAR_F77 (double *x, double *y);
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Note that we pass both the lowercase and uppercase versions of
|
|
the function name to <CODE>F77_FUNC</CODE> so that
|
|
it can select the right one. Note also that all parameters to
|
|
Fortran 77 routines are passed as pointers (Mixing Fortran 77
|
|
With C and C++, , , automake, GNU Automake).</P><P>
|
|
|
|
(Replace <CODE>F77</CODE> with
|
|
<CODE>FC</CODE> for Fortran instead of Fortran 77.)</P><P>
|
|
|
|
Although Autoconf tries to be intelligent about detecting the
|
|
name-mangling scheme of the Fortran compiler, there may be
|
|
Fortran compilers that it doesn't support yet. In this case,
|
|
the above code generates a compile-time error, but some other
|
|
behavior (e.g., disabling Fortran-related features) can be
|
|
induced by checking whether <CODE>F77_FUNC</CODE> or
|
|
<CODE>FC_FUNC</CODE> is defined.</P><P>
|
|
|
|
Now, to call that routine from a C program, we would do
|
|
something like:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> double x = 2.7183, y;
|
|
FOOBAR_F77 (&x, &y); @
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If the Fortran identifier contains an underscore (e.g.,
|
|
<CODE>foo_bar</CODE>), you should use
|
|
<CODE>F77_FUNC_</CODE> or
|
|
<CODE>FC_FUNC_</CODE> instead of
|
|
<CODE>F77_FUNC</CODE> or
|
|
<CODE>FC_FUNC</CODE> (with the same arguments).
|
|
This is because some Fortran compilers mangle names differently
|
|
if they contain an underscore.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_F77_FUNC">
|
|
<prototype>
|
|
<parameter content="name"/>
|
|
<parameter content="[shellvar]"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="name"/>
|
|
<parameter content="[shellvar]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Given an identifier <VAR>name</VAR>, set the shell
|
|
variable <VAR>shellvar</VAR> to hold the mangled
|
|
version <VAR>name</VAR> according to the rules of
|
|
the Fortran linker (see also
|
|
<CODE>AC_F77_WRAPPERS</CODE> or
|
|
<CODE>AC_FC_WRAPPERS</CODE>).
|
|
<VAR>shellvar</VAR> is optional; if it is not
|
|
supplied, the shell variable is simply
|
|
<VAR>name</VAR>. The purpose of this macro is to
|
|
give the caller a way to access the name-mangling information
|
|
other than through the C preprocessor as above, for example, to
|
|
call Fortran routines from some language other than C/C++.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FC_SRCEXT">
|
|
<prototype>
|
|
<parameter content="ext"/>
|
|
<parameter content="[action-if-success]"/>
|
|
<parameter content="@ [action-if-failure]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
By default, the <CODE>FC</CODE> macros perform
|
|
their tests using a <TT>.f</TT> extension for
|
|
source-code files. Some compilers, however, only enable newer
|
|
language features for appropriately named files, e.g., Fortran
|
|
90 features only for <TT>.f90</TT> files. On the
|
|
other hand, some other compilers expect all source files to end
|
|
in <TT>.f</TT> and require special flags to support
|
|
other file name extensions. The
|
|
<CODE>AC_FC_SRCEXT</CODE> macro deals with both of
|
|
these issues.</P><P>
|
|
|
|
The <CODE>AC_FC_SRCEXT</CODE> tries to get the
|
|
<CODE>FC</CODE> compiler to accept files ending with
|
|
the extension .<VAR>ext</VAR> (i.e.,
|
|
<VAR>ext</VAR> does <EM>not</EM> contain
|
|
the dot). If any special compiler flags are needed for this, it
|
|
stores them in the output variable
|
|
<CODE>FCFLAGS_</CODE><VAR>ext</VAR>.
|
|
This extension and these flags are then used for all subsequent
|
|
<CODE>FC</CODE> tests (until
|
|
<CODE>AC_FC_SRCEXT</CODE> is called again).</P><P>
|
|
|
|
For example, you would use
|
|
<CODE>AC_FC_SRCEXT(f90)</CODE> to employ the
|
|
<TT>.f90</TT> extension in future tests, and it
|
|
would set the <CODE>FCFLAGS_f90</CODE> output
|
|
variable with any extra flags that are needed to compile such
|
|
files.</P><P>
|
|
|
|
The <CODE>FCFLAGS_</CODE><VAR>ext</VAR>
|
|
can <EM>not</EM> be simply absorbed into
|
|
<CODE>FCFLAGS</CODE>, for two reasons based on the
|
|
limitations of some compilers. First, only one
|
|
<CODE>FCFLAGS_</CODE><VAR>ext</VAR> can
|
|
be used at a time, so files with different extensions must be
|
|
compiled separately. Second,
|
|
<CODE>FCFLAGS_</CODE><VAR>ext</VAR> must
|
|
appear <EM>immediately</EM> before the source-code
|
|
file name when compiling. So, continuing the example above, you
|
|
might compile a <TT>foo.f90</TT> file in your
|
|
makefile with the command:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> foo.o: foo.f90 $(FC) -c
|
|
$(FCFLAGS) $(FCFLAGS_f90) '$(srcdir)/foo.f90'
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If <CODE>AC_FC_SRCEXT</CODE> succeeds in compiling
|
|
files with the <VAR>ext</VAR> extension, it calls
|
|
<VAR>action-if-success</VAR> (defaults to nothing).
|
|
If it fails, and cannot find a way to make the
|
|
<CODE>FC</CODE> compiler accept such files, it calls
|
|
<VAR>action-if-failure</VAR> (defaults to exiting
|
|
with an error message).</P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FC_FREEFORM">
|
|
<prototype>
|
|
<parameter content="[action-if-success]"/>
|
|
<parameter content="[action-if-failure]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
The <CODE>AC_FC_FREEFORM</CODE> tries to ensure that
|
|
the Fortran compiler (<CODE>$FC</CODE>) allows
|
|
free-format source code (as opposed to the older fixed-format
|
|
style from Fortran 77). If necessary, it may add some
|
|
additional flags to <CODE>FCFLAGS</CODE>.</P><P>
|
|
|
|
This macro is most important if you are using the default
|
|
<TT>.f</TT> extension, since many compilers
|
|
interpret this extension as indicating fixed-format source
|
|
unless an additional flag is supplied. If you specify a
|
|
different extension with <CODE>AC_FC_SRCEXT</CODE>,
|
|
such as <TT>.f90</TT>, then
|
|
<CODE>AC_FC_FREEFORM</CODE> ordinarily succeeds
|
|
without modifying <CODE>FCFLAGS</CODE>. For
|
|
extensions which the compiler does not know about, the flag set
|
|
by the <CODE>AC_FC_SRCEXT</CODE> macro might let the
|
|
compiler assume Fortran 77 by default, however.</P><P>
|
|
|
|
If <CODE>AC_FC_FREEFORM</CODE> succeeds in compiling
|
|
free-form source, it calls
|
|
<VAR>action-if-success</VAR> (defaults to nothing).
|
|
If it fails, it calls <VAR>action-if-failure</VAR>
|
|
(defaults to exiting with an error message).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FC_FIXEDFORM">
|
|
<prototype>
|
|
<parameter content="[action-if-success]"/>
|
|
<parameter content="[action-if-failure]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
The <CODE>AC_FC_FIXEDFORM</CODE> tries to ensure
|
|
that the Fortran compiler (<CODE>$FC</CODE>) allows
|
|
the old fixed-format source code (as opposed to free-format
|
|
style). If necessary, it may add some additional flags to
|
|
<CODE>FCFLAGS</CODE>.</P><P>
|
|
|
|
This macro is needed for some compilers alias names like
|
|
<CODE>xlf95</CODE> which assume free-form source
|
|
code by default, and in case you want to use fixed-form source
|
|
with an extension like <TT>.f90</TT> which many
|
|
compilers interpret as free-form by default. If you specify a
|
|
different extension with <CODE>AC_FC_SRCEXT</CODE>,
|
|
such as <TT>.f</TT>, then
|
|
<CODE>AC_FC_FIXEDFORM</CODE> ordinarily succeeds
|
|
without modifying <CODE>FCFLAGS</CODE>.</P><P>
|
|
|
|
If <CODE>AC_FC_FIXEDFORM</CODE> succeeds in
|
|
compiling fixed-form source, it calls
|
|
<VAR>action-if-success</VAR> (defaults to nothing).
|
|
If it fails, it calls <VAR>action-if-failure</VAR>
|
|
(defaults to exiting with an error message).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FC_LINE_LENGTH">
|
|
<prototype>
|
|
<parameter content="[length]"/>
|
|
<parameter content="[action-if-success]"/>
|
|
<parameter content="@ [action-if-failure]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
The <CODE>AC_FC_LINE_LENGTH</CODE> macro tries to
|
|
ensure that the Fortran compiler (<CODE>$FC</CODE>)
|
|
accepts long source code lines. The
|
|
<VAR>length</VAR> argument may be given as 80, 132,
|
|
or unlimited, and defaults to 132. Note that line lengths above
|
|
254 columns are not portable, and some compilers do not accept
|
|
more than 132 columns at least for fixed format source. If
|
|
necessary, it may add some additional flags to
|
|
<CODE>FCFLAGS</CODE>.</P><P>
|
|
|
|
If <CODE>AC_FC_LINE_LENGTH</CODE> succeeds in
|
|
compiling fixed-form source, it calls
|
|
<VAR>action-if-success</VAR> (defaults to nothing).
|
|
If it fails, it calls <VAR>action-if-failure</VAR>
|
|
(defaults to exiting with an error message).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PATH_X">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Window System Try to locate the X Window System include files
|
|
and libraries. If the user gave the command line options
|
|
<samp>--x-includes=<VAR>dir</VAR></samp>
|
|
and
|
|
<samp>--x-libraries=<VAR>dir</VAR></samp>,
|
|
use those directories.</P><P>
|
|
|
|
If either or both were not given, get the missing values by
|
|
running <CODE>xmkmf</CODE> (or an executable pointed
|
|
to by the <CODE>XMKMF</CODE> environment variable)
|
|
on a trivial <TT>Imakefile</TT> and examining the
|
|
makefile that it produces. Setting
|
|
<CODE>XMKMF</CODE> to <samp>false</samp>
|
|
disables this method.</P><P>
|
|
|
|
If this method fails to find the X Window System,
|
|
<CODE>configure</CODE> looks for the files in
|
|
several directories where they often reside. If either method is
|
|
successful, set the shell variables
|
|
<CODE>x_includes</CODE> and
|
|
<CODE>x_libraries</CODE> to their locations, unless
|
|
they are in directories the compiler searches by default.</P><P>
|
|
|
|
If both methods fail, or the user gave the command line option
|
|
<samp>--without-x</samp>, set the shell variable
|
|
<CODE>no_x</CODE> to <samp>yes</samp>;
|
|
otherwise set it to the empty string.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PATH_XTRA">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
An enhanced version of <CODE>AC_PATH_X</CODE>.
|
|
It adds the C compiler flags that X needs to output variable
|
|
<CODE>X_CFLAGS</CODE>, and the X linker flags to
|
|
<CODE>X_LIBS</CODE>. Define
|
|
<CODE>X_DISPLAY_MISSING</CODE> if X is not
|
|
available.</P><P>
|
|
|
|
This macro also checks for special libraries that some systems
|
|
need in order to compile X programs. It adds any that the
|
|
system needs to output variable
|
|
<CODE>X_EXTRA_LIBS</CODE>. And it checks for
|
|
special X11R6 libraries that need to be linked with before
|
|
<samp>-lX11</samp>, and adds any found to the output
|
|
variable <CODE>X_PRE_LIBS</CODE>.</P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SYS_INTERPRETER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check whether the system supports starting scripts with a line
|
|
of the form <samp>#!/bin/sh</samp> to select the
|
|
interpreter to use for the script. After running this macro,
|
|
shell code in <TT>configure.ac</TT> can check the
|
|
shell variable <CODE>interpval</CODE>; it is set to
|
|
<samp>yes</samp> if the system supports
|
|
<samp>#!</samp>, <samp>no</samp> if not.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SYS_LARGEFILE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
file support Arrange for 64-bit file offsets, known as
|
|
http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
|
|
large-file support. On some hosts, one must use special
|
|
compiler options to build programs that can access large files.
|
|
Append any such options to the output variable
|
|
<CODE>CC</CODE>. Define
|
|
<CODE>_FILE_OFFSET_BITS</CODE> and
|
|
<CODE>_LARGE_FILES</CODE> if necessary.</P><P>
|
|
|
|
Large-file support can be disabled by configuring with the
|
|
<samp>--disable-largefile</samp> option.</P><P>
|
|
|
|
If you use this macro, check that your program works even when
|
|
<CODE>off_t</CODE> is wider than <CODE>long
|
|
int</CODE>, since this is common when large-file support
|
|
is enabled. For example, it is not correct to print an
|
|
arbitrary <CODE>off_t</CODE> value
|
|
<CODE>X</CODE> with <CODE>printf ("%ld", (long
|
|
int) X)</CODE>.</P><P>
|
|
|
|
The LFS introduced the <CODE>fseeko</CODE> and
|
|
<CODE>ftello</CODE> functions to replace their C
|
|
counterparts <CODE>fseek</CODE> and
|
|
<CODE>ftell</CODE> that do not use
|
|
<CODE>off_t</CODE>. Take care to use
|
|
<CODE>AC_FUNC_FSEEKO</CODE> to make their prototypes
|
|
available when using them and large-file support is enabled.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SYS_LONG_FILE_NAMES">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the system supports file names longer than 14 characters,
|
|
define <CODE>HAVE_LONG_FILE_NAMES</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SYS_POSIX_TERMIOS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
termios headers Posix headers Check to see if the Posix
|
|
termios headers and functions are available on the system. If
|
|
so, set the shell variable
|
|
<CODE>ac_cv_sys_posix_termios</CODE> to
|
|
<samp>yes</samp>. If not, set the variable to
|
|
<samp>no</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_USE_SYSTEM_EXTENSIONS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.60. If
|
|
possible, enable extensions to C or Posix on hosts that normally
|
|
disable the extensions, typically due to standards-conformance
|
|
namespace issues. This should be called before any macros that
|
|
run the C compiler. The following preprocessor macros are
|
|
defined where appropriate:</P><P>
|
|
|
|
@table @code <LI> _GNU_SOURCE Enable extensions on
|
|
GNU/Linux. <LI> __EXTENSIONS__ Enable general extensions
|
|
on Solaris. <LI> _POSIX_PTHREAD_SEMANTICS Enable threading
|
|
extensions on Solaris. <LI> _TANDEM_SOURCE Enable
|
|
extensions for the HP NonStop platform. <LI> _ALL_SOURCE
|
|
Enable extensions for AIX 3, and for Interix. <LI>
|
|
_POSIX_SOURCE Enable Posix functions for Minix. <LI>
|
|
_POSIX_1_SOURCE Enable additional Posix functions for Minix.
|
|
<LI> _MINIX Identify Minix platform. This particular
|
|
preprocessor macro is obsolescent, and may be removed in a
|
|
future release of Autoconf. </DL>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_SUBST_ERTS_VER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set the output variable
|
|
<CODE>ERLANG_ERTS_VER</CODE> to the version of the
|
|
Erlang runtime system (as returned by Erlang's
|
|
<CODE>erlang:system_info(version)</CODE> function).
|
|
The result of this test is cached if caching is enabled when
|
|
running <CODE>configure</CODE>. The
|
|
<CODE>ERLANG_ERTS_VER</CODE> variable is not
|
|
intended to be used for testing for features of specific ERTS
|
|
versions, but to be used for substituting the ERTS version in
|
|
Erlang/OTP release resource files (<CODE>.rel</CODE>
|
|
files), as shown below.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_SUBST_ROOT_DIR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set the output variable
|
|
<CODE>ERLANG_ROOT_DIR</CODE> to the path to the base
|
|
directory in which Erlang/OTP is installed (as returned by
|
|
Erlang's <CODE>code:root_dir/0</CODE> function).
|
|
The result of this test is cached if caching is enabled when
|
|
running <CODE>configure</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_SUBST_LIB_DIR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set the output variable
|
|
<CODE>ERLANG_LIB_DIR</CODE> to the path of the
|
|
library directory of Erlang/OTP (as returned by Erlang's
|
|
<CODE>code:lib_dir/0</CODE> function), which
|
|
subdirectories each contain an installed Erlang/OTP library.
|
|
The result of this test is cached if caching is enabled when
|
|
running <CODE>configure</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_CHECK_LIB">
|
|
<prototype>
|
|
<parameter content="library"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Test whether the Erlang/OTP library
|
|
<VAR>library</VAR> is installed by calling Erlang's
|
|
<CODE>code:lib_dir/1</CODE> function. The result of
|
|
this test is cached if caching is enabled when running
|
|
<CODE>configure</CODE>.
|
|
<VAR>action-if-found</VAR> is a list of shell
|
|
commands to run if the library is installed;
|
|
<VAR>action-if-not-found</VAR> is a list of shell
|
|
commands to run if it is not. Additionally, if the library is
|
|
installed, the output variable
|
|
<samp>ERLANG_LIB_DIR_<VAR>library</VAR></samp>
|
|
is set to the path to the library installation directory, and
|
|
the output variable
|
|
<samp>ERLANG_LIB_VER_<VAR>library</VAR></samp>
|
|
is set to the version number that is part of the subdirectory
|
|
name, if it is in the standard form
|
|
(<CODE><VAR>library</VAR>-<VAR>version</VAR></CODE>).
|
|
If the directory name does not have a version part,
|
|
<samp>ERLANG_LIB_VER_<VAR>library</VAR></samp>
|
|
is set to the empty string. If the library is not installed,
|
|
<samp>ERLANG_LIB_DIR_<VAR>library</VAR></samp>
|
|
and
|
|
<samp>ERLANG_LIB_VER_<VAR>library</VAR></samp>
|
|
are set to <CODE>"not found"</CODE>. For example,
|
|
to check if library <CODE>stdlib</CODE> is
|
|
installed:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ERLANG_CHECK_LIB([stdlib],
|
|
[echo "stdlib version \"$ERLANG_LIB_VER_stdlib\"" echo "is
|
|
installed in \"$ERLANG_LIB_DIR_stdlib\""],
|
|
[AC_MSG_ERROR([stdlib was not found!])])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The
|
|
<samp>ERLANG_LIB_VER_<VAR>library</VAR></samp>
|
|
variables (set by <CODE>AC_ERLANG_CHECK_LIB</CODE>)
|
|
and the <CODE>ERLANG_ERTS_VER</CODE> variable (set
|
|
by <CODE>AC_ERLANG_SUBST_ERTS_VER</CODE>) are not
|
|
intended to be used for testing for features of specific
|
|
versions of libraries or of the Erlang runtime system. Those
|
|
variables are intended to be substituted in Erlang release
|
|
resource files (<CODE>.rel</CODE> files). For
|
|
instance, to generate a <TT>example.rel</TT> file
|
|
for an application depending on the
|
|
<CODE>stdlib</CODE> library,
|
|
<TT>configure.ac</TT> could contain:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ERLANG_SUBST_ERTS_VER
|
|
AC_ERLANG_CHECK_LIB([stdlib], [], [AC_MSG_ERROR([stdlib was
|
|
not found!])]) AC_CONFIG_FILES([example.rel])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The <TT>example.rel.in</TT> file used to generate
|
|
<TT>example.rel</TT> should contain:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> release, "@@PACKAGE@@",
|
|
"@@VERSION@@"@, erts, "@@ERLANG_ERTS_VER@@"@, [stdlib,
|
|
"@@ERLANG_LIB_VER_stdlib@@"@, @@PACKAGE@@,
|
|
"@@VERSION@@"@]@.
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_SUBST_INSTALL_LIB_DIR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
Set the <CODE>ERLANG_INSTALL_LIB_DIR</CODE> output
|
|
variable to the directory into which every built Erlang library
|
|
should be installed in a separate subdirectory. If this variable
|
|
is not set in the environment when
|
|
<CODE>configure</CODE> runs, its default value is
|
|
<CODE>$libdir@</CODE>/erlang/lib.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR">
|
|
<prototype>
|
|
<parameter content="library"/>
|
|
<parameter content="version"/>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
Set the
|
|
<samp>ERLANG_INSTALL_LIB_DIR_<VAR>library</VAR></samp>
|
|
output variable to the directory into which the built Erlang
|
|
library <VAR>library</VAR> version
|
|
<VAR>version</VAR> should be installed. If this
|
|
variable is not set in the environment when
|
|
<CODE>configure</CODE> runs, its default value is
|
|
<samp>$ERLANG_INSTALL_LIB_DIR/<VAR>library</VAR>-<VAR>version</VAR></samp>,
|
|
the value of the <CODE>ERLANG_INSTALL_LIB_DIR</CODE>
|
|
variable being set by the
|
|
<CODE>AC_ERLANG_SUBST_INSTALL_LIB_DIR</CODE> macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG">
|
|
<prototype>
|
|
<parameter content="language"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Do compilation tests using the compiler, preprocessor, and file
|
|
extensions for the specified <VAR>language</VAR>.</P><P>
|
|
|
|
Supported languages are:</P><P>
|
|
|
|
<DL> <DT>'<SAMP>C</SAMP>' <DD> Do
|
|
compilation tests using <CODE>CC</CODE> and
|
|
<CODE>CPP</CODE> and use extension
|
|
<TT>.c</TT> for test programs. Use compilation
|
|
flags: <CODE>CPPFLAGS</CODE> with
|
|
<CODE>CPP</CODE>, and both
|
|
<CODE>CPPFLAGS</CODE> and
|
|
<CODE>CFLAGS</CODE> with
|
|
<CODE>CC</CODE>.</P><P>
|
|
|
|
<DT>'<SAMP>C++</SAMP>' <DD> Do
|
|
compilation tests using <CODE>CXX</CODE> and
|
|
<CODE>CXXCPP</CODE> and use extension
|
|
<TT>.C</TT> for test programs. Use compilation
|
|
flags: <CODE>CPPFLAGS</CODE> with
|
|
<CODE>CXXCPP</CODE>, and both
|
|
<CODE>CPPFLAGS</CODE> and
|
|
<CODE>CXXFLAGS</CODE> with
|
|
<CODE>CXX</CODE>.</P><P>
|
|
|
|
<DT>'<SAMP>Fortran 77</SAMP>' <DD> Do
|
|
compilation tests using <CODE>F77</CODE> and use
|
|
extension <TT>.f</TT> for test programs. Use
|
|
compilation flags: <CODE>FFLAGS</CODE>.</P><P>
|
|
|
|
<DT>'<SAMP>Fortran</SAMP>' <DD> Do
|
|
compilation tests using <CODE>FC</CODE> and use
|
|
extension <TT>.f</TT> (or whatever has been set by
|
|
<CODE>AC_FC_SRCEXT</CODE>) for test programs. Use
|
|
compilation flags: <CODE>FCFLAGS</CODE>.</P><P>
|
|
|
|
<DT>'<SAMP>Erlang</SAMP>' <DD>
|
|
Compile and execute tests using <CODE>ERLC</CODE>
|
|
and <CODE>ERL</CODE> and use extension
|
|
<TT>.erl</TT> for test Erlang modules. Use
|
|
compilation flags: <CODE>ERLCFLAGS</CODE>.</P><P>
|
|
|
|
<DT>'<SAMP>Objective C</SAMP>' <DD> Do
|
|
compilation tests using <CODE>OBJC</CODE> and
|
|
<CODE>OBJCPP</CODE> and use extension
|
|
<TT>.m</TT> for test programs. Use compilation
|
|
flags: <CODE>CPPFLAGS</CODE> with
|
|
<CODE>OBJCPP</CODE>, and both
|
|
<CODE>CPPFLAGS</CODE> and
|
|
<CODE>OBJCFLAGS</CODE> with
|
|
<CODE>OBJC</CODE>.</P><P>
|
|
|
|
<DT>'<SAMP>Objective C++</SAMP>' <DD> Do
|
|
compilation tests using <CODE>OBJCXX</CODE> and
|
|
<CODE>OBJCXXCPP</CODE> and use extension
|
|
<TT>.mm</TT> for test programs. Use compilation
|
|
flags: <CODE>CPPFLAGS</CODE> with
|
|
<CODE>OBJCXXCPP</CODE>, and both
|
|
<CODE>CPPFLAGS</CODE> and
|
|
<CODE>OBJCXXFLAGS</CODE> with
|
|
<CODE>OBJCXX</CODE>. </DL>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_PUSH">
|
|
<prototype>
|
|
<parameter content="language"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Remember the current language (as set by
|
|
<CODE>AC_LANG</CODE>) on a stack, and then select
|
|
the <VAR>language</VAR>. Use this macro and
|
|
<CODE>AC_LANG_POP</CODE> in macros that need to
|
|
temporarily switch to a particular language.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_POP">
|
|
<prototype>
|
|
<parameter content="[language]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Select the language that is saved on the top of the stack, as
|
|
set by <CODE>AC_LANG_PUSH</CODE>, and remove it from
|
|
the stack.</P><P>
|
|
|
|
If given, <VAR>language</VAR> specifies the language
|
|
we just <EM>quit</EM>. It is a good idea to specify
|
|
it when it's known (which should be the
|
|
case<small>...</small>), since Autoconf detects
|
|
inconsistencies.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_LANG_PUSH([Fortran 77]) #
|
|
Perform some tests on Fortran 77. #
|
|
<small>...</small> AC_LANG_POP([Fortran 77])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_ASSERT">
|
|
<prototype>
|
|
<parameter content="language"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Check statically that the current language is
|
|
<VAR>language</VAR>. You should use this in your
|
|
language specific macros to avoid that they be called with an
|
|
inappropriate language.</P><P>
|
|
|
|
This macro runs only at <CODE>autoconf</CODE> time,
|
|
and incurs no cost at <CODE>configure</CODE> time.
|
|
Sadly enough and because Autoconf is a two layer language
|
|
Because M4 is not aware of Sh code, especially conditionals,
|
|
some optimizations that look nice statically may produce
|
|
incorrect results at runtime., the macros
|
|
<CODE>AC_LANG_PUSH</CODE> and
|
|
<CODE>AC_LANG_POP</CODE> cannot be ``optimizing'',
|
|
therefore as much as possible you ought to avoid using them to
|
|
wrap your code, rather, require from the user to run the macro
|
|
with a correct current language, and check it with
|
|
<CODE>AC_LANG_ASSERT</CODE>. And anyway, that may
|
|
help the user understand she is running a Fortran macro while
|
|
expecting a result about her Fortran 77 compiler
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_REQUIRE_CPP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Ensure that whichever preprocessor would currently be used for
|
|
tests has been found. Calls <CODE>AC_REQUIRE</CODE>
|
|
(Prerequisite Macros) with an argument of either
|
|
<CODE>AC_PROG_CPP</CODE> or
|
|
<CODE>AC_PROG_CXXCPP</CODE>, depending on which
|
|
language is current.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_CONFTEST">
|
|
<prototype>
|
|
<parameter content="source"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Save the <VAR>source</VAR> text in the current test
|
|
source file:
|
|
<TT>conftest.<VAR>extension</VAR></TT>
|
|
where the <VAR>extension</VAR> depends on the
|
|
current language. As of Autoconf 2.63b, the source file also
|
|
contains the results of all of the
|
|
<CODE>AC_DEFINE</CODE> performed so far.</P><P>
|
|
|
|
Note that the <VAR>source</VAR> is evaluated exactly
|
|
once, like regular Autoconf macro arguments, and therefore (i)
|
|
you may pass a macro invocation, (ii) if not, be sure to double
|
|
quote if needed.</P><P>
|
|
|
|
This macro issues a warning during
|
|
<CODE>autoconf</CODE> processing if
|
|
<VAR>source</VAR> does not include an expansion of
|
|
the macro <CODE>AC_LANG_DEFINES_PROVIDED</CODE>
|
|
(note that both <CODE>AC_LANG_SOURCE</CODE> and
|
|
<CODE>AC_LANG_PROGRAM</CODE> call this macro, and
|
|
thus avoid the warning).</P><P>
|
|
|
|
This macro is seldom called directly, but is used under the hood
|
|
by more common macros such as
|
|
<CODE>AC_COMPILE_IFELSE</CODE> and
|
|
<CODE>AC_RUN_IFELSE</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_DEFINES_PROVIDED">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is called as a witness that the file
|
|
<TT>conftest.<VAR>extension</VAR></TT>
|
|
appropriate for the current language is complete, including all
|
|
previously determined results from
|
|
<CODE>AC_DEFINE</CODE>. This macro is seldom called
|
|
directly, but exists if you have a compelling reason to write a
|
|
conftest file without using
|
|
<CODE>AC_LANG_SOURCE</CODE>, yet still want to avoid
|
|
a syntax warning from <CODE>AC_LANG_CONFTEST</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_SOURCE">
|
|
<prototype>
|
|
<parameter content="source"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands into the <VAR>source</VAR>, with the
|
|
definition of all the <CODE>AC_DEFINE</CODE>
|
|
performed so far. This macro includes an expansion of
|
|
<CODE>AC_LANG_DEFINES_PROVIDED</CODE>.</P><P>
|
|
|
|
In many cases, you may find it more convenient to use the
|
|
wrapper <CODE>AC_LANG_PROGRAM</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_PROGRAM">
|
|
<prototype>
|
|
<parameter content="prologue"/>
|
|
<parameter content="body"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands into a source file which consists of the
|
|
<VAR>prologue</VAR>, and then
|
|
<VAR>body</VAR> as body of the main function (e.g.,
|
|
<CODE>main</CODE> in C). Since it uses
|
|
<CODE>AC_LANG_SOURCE</CODE>, the features of the
|
|
latter are available.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_CALL">
|
|
<prototype>
|
|
<parameter content="prologue"/>
|
|
<parameter content="function"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands into a source file which consists of the
|
|
<VAR>prologue</VAR>, and then a call to the
|
|
<VAR>function</VAR> as body of the main function
|
|
(e.g., <CODE>main</CODE> in C). Since it uses
|
|
<CODE>AC_LANG_PROGRAM</CODE>, the feature of the
|
|
latter are available.</P><P>
|
|
|
|
This function will probably be replaced in the future by a
|
|
version which would enable specifying the arguments. The use of
|
|
this macro is not encouraged, as it violates strongly the typing
|
|
system.</P><P>
|
|
|
|
This macro cannot be used for Erlang tests.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_FUNC_LINK_TRY">
|
|
<prototype>
|
|
<parameter content="function"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands into a source file which uses the
|
|
<VAR>function</VAR> in the body of the main function
|
|
(e.g., <CODE>main</CODE> in C). Since it uses
|
|
<CODE>AC_LANG_PROGRAM</CODE>, the features of the
|
|
latter are available.</P><P>
|
|
|
|
As <CODE>AC_LANG_CALL</CODE>, this macro is
|
|
documented only for completeness. It is considered to be
|
|
severely broken, and in the future will be removed in favor of
|
|
actual function calls (with properly typed arguments).</P><P>
|
|
|
|
This macro cannot be used for Erlang tests.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PREPROC_IFELSE">
|
|
<prototype>
|
|
<parameter content="input"/>
|
|
<parameter content="[action-if-true]"/>
|
|
<parameter content="@ [action-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Run the preprocessor of the current language (Language Choice)
|
|
on the <VAR>input</VAR>, run the shell commands
|
|
<VAR>action-if-true</VAR> on success,
|
|
<VAR>action-if-false</VAR> otherwise. The
|
|
<VAR>input</VAR> can be made by
|
|
<CODE>AC_LANG_PROGRAM</CODE> and friends.</P><P>
|
|
|
|
This macro uses <CODE>CPPFLAGS</CODE>, but not
|
|
<CODE>CFLAGS</CODE>, because
|
|
<samp>-g</samp>, <samp>-O</samp>, etc.@:
|
|
are not valid options to many C preprocessors.</P><P>
|
|
|
|
It is customary to report unexpected failures with
|
|
<CODE>AC_MSG_FAILURE</CODE>. If needed,
|
|
<VAR>action-if-true</VAR> can further access the
|
|
preprocessed output in the file <TT>conftest.i</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_EGREP_HEADER">
|
|
<prototype>
|
|
<parameter content="pattern"/>
|
|
<parameter content="header-file"/>
|
|
<parameter content="@ action-if-found"/>
|
|
<parameter content="[action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If the output of running the preprocessor on the system header
|
|
file <VAR>header-file</VAR> matches the extended
|
|
regular expression <VAR>pattern</VAR>, execute shell
|
|
commands <VAR>action-if-found</VAR>, otherwise
|
|
execute <VAR>action-if-not-found</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_EGREP_CPP">
|
|
<prototype>
|
|
<parameter content="pattern"/>
|
|
<parameter content="program"/>
|
|
<parameter content="@ [action-if-found]"/>
|
|
<parameter content="[action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
<VAR>program</VAR> is the text of a C or C++
|
|
program, on which shell variable, back quote, and backslash
|
|
substitutions are performed. If the output of running the
|
|
preprocessor on <VAR>program</VAR> matches the
|
|
extended regular expression <VAR>pattern</VAR>,
|
|
execute shell commands <VAR>action-if-found</VAR>,
|
|
otherwise execute <VAR>action-if-not-found</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_COMPILE_IFELSE">
|
|
<prototype>
|
|
<parameter content="input"/>
|
|
<parameter content="[action-if-true]"/>
|
|
<parameter content="@ [action-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Run the compiler and compilation flags of the current language
|
|
(Language Choice) on the <VAR>input</VAR>, run the
|
|
shell commands <VAR>action-if-true</VAR> on success,
|
|
<VAR>action-if-false</VAR> otherwise. The
|
|
<VAR>input</VAR> can be made by
|
|
<CODE>AC_LANG_PROGRAM</CODE> and friends.</P><P>
|
|
|
|
It is customary to report unexpected failures with
|
|
<CODE>AC_MSG_FAILURE</CODE>. This macro does not
|
|
try to link; use <CODE>AC_LINK_IFELSE</CODE> if you
|
|
need to do that (Running the Linker). If needed,
|
|
<VAR>action-if-true</VAR> can further access the
|
|
just-compiled object file <TT>conftest.$OBJEXT</TT>.</P><P>
|
|
|
|
This macro uses <CODE>AC_REQUIRE</CODE> for the
|
|
compiler associated with the current language, which means that
|
|
if the compiler has not yet been determined, the compiler
|
|
determination will be made prior to the body of the outermust
|
|
<CODE>AC_DEFUN</CODE> macro that triggered this
|
|
macro to expand (Expanded Before Required).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LINK_IFELSE">
|
|
<prototype>
|
|
<parameter content="input"/>
|
|
<parameter content="[action-if-true]"/>
|
|
<parameter content="@ [action-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Run the compiler (and compilation flags) and the linker of the
|
|
current language (Language Choice) on the
|
|
<VAR>input</VAR>, run the shell commands
|
|
<VAR>action-if-true</VAR> on success,
|
|
<VAR>action-if-false</VAR> otherwise. The
|
|
<VAR>input</VAR> can be made by
|
|
<CODE>AC_LANG_PROGRAM</CODE> and friends. If
|
|
needed, <VAR>action-if-true</VAR> can further access
|
|
the just-linked program file
|
|
<TT>conftest$EXEEXT</TT>.</P><P>
|
|
|
|
<CODE>LDFLAGS</CODE> and
|
|
<CODE>LIBS</CODE> are used for linking, in addition
|
|
to the current compilation flags.</P><P>
|
|
|
|
It is customary to report unexpected failures with
|
|
<CODE>AC_MSG_FAILURE</CODE>. This macro does not
|
|
try to execute the program; use
|
|
<CODE>AC_RUN_IFELSE</CODE> if you need to do that
|
|
(Runtime).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_RUN_IFELSE">
|
|
<prototype>
|
|
<parameter content="input"/>
|
|
<parameter content="[action-if-true]"/>
|
|
<parameter content="@ [action-if-false]"/>
|
|
<parameter content="[action-if-cross-compiling]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If <VAR>program</VAR> compiles and links
|
|
successfully and returns an exit status of 0 when executed, run
|
|
shell commands <VAR>action-if-true</VAR>. Otherwise,
|
|
run shell commands <VAR>action-if-false</VAR>.</P><P>
|
|
|
|
The <VAR>input</VAR> can be made by
|
|
<CODE>AC_LANG_PROGRAM</CODE> and friends.
|
|
<CODE>LDFLAGS</CODE> and
|
|
<CODE>LIBS</CODE> are used for linking, in addition
|
|
to the compilation flags of the current language (Language
|
|
Choice). Additionally, <VAR>action-if-true</VAR> can
|
|
run <CODE>./conftest$EXEEXT</CODE> for further
|
|
testing.</P><P>
|
|
|
|
If the compiler being used does not produce executables that run
|
|
on the system where <CODE>configure</CODE> is being
|
|
run, then the test program is not run. If the optional shell
|
|
commands <VAR>action-if-cross-compiling</VAR> are
|
|
given, they are run instead. Otherwise,
|
|
<CODE>configure</CODE> prints an error message and
|
|
exits.</P><P>
|
|
|
|
In the <VAR>action-if-false</VAR> section, the
|
|
failing exit status is available in the shell variable
|
|
<samp>$?</samp>. This exit status might be that of
|
|
a failed compilation, or it might be that of a failed program
|
|
execution.</P><P>
|
|
|
|
It is customary to report unexpected failures with
|
|
<CODE>AC_MSG_FAILURE</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DEFINE">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="value"/>
|
|
<parameter content="[description]"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <VAR>variable</VAR> to
|
|
<VAR>value</VAR> (verbatim), by defining a C
|
|
preprocessor macro for <VAR>variable</VAR>.
|
|
<VAR>variable</VAR> should be a C identifier,
|
|
optionally suffixed by a parenthesized argument list to define a
|
|
C preprocessor macro with arguments. The macro argument list,
|
|
if present, should be a comma-separated list of C identifiers,
|
|
possibly terminated by an ellipsis <samp>...</samp>
|
|
if C99 syntax is employed. <VAR>variable</VAR>
|
|
should not contain comments, white space, trigraphs,
|
|
backslash-newlines, universal character names, or non-ASCII
|
|
characters.</P><P>
|
|
|
|
<VAR>value</VAR> may contain backslash-escaped
|
|
newlines, which will be preserved if you use
|
|
<CODE>AC_CONFIG_HEADERS</CODE> but flattened if
|
|
passed via <CODE>@@DEFS@@</CODE> (with no effect on
|
|
the compilation, since the preprocessor sees only one line in
|
|
the first place). <VAR>value</VAR> should not
|
|
contain raw newlines. If you are not using
|
|
<CODE>AC_CONFIG_HEADERS</CODE>,
|
|
<VAR>value</VAR> should not contain any
|
|
<samp>#</samp> characters, as
|
|
<CODE>make</CODE> tends to eat them. To use a shell
|
|
variable, use <CODE>AC_DEFINE_UNQUOTED</CODE>
|
|
instead.</P><P>
|
|
|
|
<VAR>description</VAR> is only useful if you are
|
|
using <CODE>AC_CONFIG_HEADERS</CODE>. In this case,
|
|
<VAR>description</VAR> is put into the generated
|
|
<TT>config.h.in</TT> as the comment before the macro
|
|
define. The following example defines the C preprocessor
|
|
variable <CODE>EQUATION</CODE> to be the string
|
|
constant <samp>"$a > $b"</samp>:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_DEFINE([EQUATION], ["$a >
|
|
$b"], [Equation string.])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If neither <VAR>value</VAR> nor
|
|
<VAR>description</VAR> are given, then
|
|
<VAR>value</VAR> defaults to 1 instead of to the
|
|
empty string. This is for backwards compatibility with older
|
|
versions of Autoconf, but this usage is obsolescent and may be
|
|
withdrawn in future versions of Autoconf.</P><P>
|
|
|
|
If the <VAR>variable</VAR> is a literal string, it
|
|
is passed to <CODE>m4_pattern_allow</CODE>
|
|
(Forbidden Patterns).</P><P>
|
|
|
|
If multiple <CODE>AC_DEFINE</CODE> statements are
|
|
executed for the same <VAR>variable</VAR> name (not
|
|
counting any parenthesized argument list), the last one wins.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DEFINE_UNQUOTED">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="value"/>
|
|
<parameter content="[description]"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>AC_DEFINE</CODE>, but three shell
|
|
expansions are performed---once---on
|
|
<VAR>variable</VAR> and
|
|
<VAR>value</VAR>: variable expansion
|
|
(<samp>$</samp>), command substitution
|
|
(<samp>`</samp>), and backslash escaping
|
|
(<samp>\</samp>), as if in an unquoted
|
|
here-document. Single and double quote characters in the value
|
|
have no special meaning. Use this macro instead of
|
|
<CODE>AC_DEFINE</CODE> when
|
|
<VAR>variable</VAR> or <VAR>value</VAR>
|
|
is a shell variable. Examples:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
AC_DEFINE_UNQUOTED([config_machfile], ["$machfile"],
|
|
[Configuration machine file.]) AC_DEFINE_UNQUOTED([GETGROUPS_T],
|
|
[$ac_cv_type_getgroups], [getgroups return type.])
|
|
AC_DEFINE_UNQUOTED([$ac_tr_hdr], [1], [Translated header
|
|
name.]) </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SUBST">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="[value]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Create an output variable from a shell variable. Make
|
|
<CODE>AC_OUTPUT</CODE> substitute the variable
|
|
<VAR>variable</VAR> into output files (typically one
|
|
or more makefiles). This means that
|
|
<CODE>AC_OUTPUT</CODE> replaces instances of
|
|
<samp>@@<VAR>variable</VAR>@@</samp> in
|
|
input files with the value that the shell variable
|
|
<VAR>variable</VAR> has when
|
|
<CODE>AC_OUTPUT</CODE> is called. The value can
|
|
contain any non-<CODE>NUL</CODE> character,
|
|
including newline. If you are using Automake 1.11 or newer, for
|
|
newlines in values you might want to consider using
|
|
<CODE>AM_SUBST_NOTMAKE</CODE> to prevent
|
|
<CODE>automake</CODE> from adding a line
|
|
<CODE><VAR>variable</VAR> =
|
|
@@<VAR>variable</VAR>@@</CODE> to the
|
|
<TT>Makefile.in</TT> files (Optional, , Automake,
|
|
automake, Other things Automake recognizes).</P><P>
|
|
|
|
Variable occurrences should not overlap: e.g., an input file
|
|
should not contain
|
|
<samp>@@<VAR>var1</VAR>@@<VAR>var2</VAR>@@</samp>
|
|
if <VAR>var1</VAR> and <VAR>var2</VAR>
|
|
are variable names. The substituted value is not rescanned for
|
|
more output variables; occurrences of
|
|
<samp>@@<VAR>variable</VAR>@@</samp> in
|
|
the value are inserted literally into the output file. (The
|
|
algorithm uses the special marker
|
|
<CODE>|#_!!_#|</CODE> internally, so neither the
|
|
substituted value nor the output file may contain
|
|
<CODE>|#_!!_#|</CODE>.)</P><P>
|
|
|
|
If <VAR>value</VAR> is given, in addition assign it
|
|
to <VAR>variable</VAR>.</P><P>
|
|
|
|
The string <VAR>variable</VAR> is passed to
|
|
<CODE>m4_pattern_allow</CODE> (Forbidden Patterns).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SUBST_FILE">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Another way to create an output variable from a shell variable.
|
|
Make <CODE>AC_OUTPUT</CODE> insert (without
|
|
substitutions) the contents of the file named by shell variable
|
|
<VAR>variable</VAR> into output files. This means
|
|
that <CODE>AC_OUTPUT</CODE> replaces instances of
|
|
<samp>@@<VAR>variable</VAR>@@</samp> in
|
|
output files (such as <TT>Makefile.in</TT>) with the
|
|
contents of the file that the shell variable
|
|
<VAR>variable</VAR> names when
|
|
<CODE>AC_OUTPUT</CODE> is called. Set the variable
|
|
to <TT>/dev/null</TT> for cases that do not have a
|
|
file to insert. This substitution occurs only when the
|
|
<samp>@@<VAR>variable</VAR>@@</samp> is
|
|
on a line by itself, optionally surrounded by spaces and tabs.
|
|
The substitution replaces the whole line, including the spaces,
|
|
tabs, and the terminating newline.</P><P>
|
|
|
|
This macro is useful for inserting makefile fragments containing
|
|
special dependencies or other <CODE>make</CODE>
|
|
directives for particular host or target types into makefiles.
|
|
For example, <TT>configure.ac</TT> could contain:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_SUBST_FILE([host_frag])
|
|
host_frag=$srcdir/conf/sun4.mh
|
|
</pre></td></tr></table></P><P>
|
|
|
|
and then a <TT>Makefile.in</TT> could contain:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @@host_frag@@
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The string <VAR>variable</VAR> is passed to
|
|
<CODE>m4_pattern_allow</CODE> (Forbidden Patterns).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ARG_VAR">
|
|
<prototype>
|
|
<parameter content="variable"/>
|
|
<parameter content="description"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Declare <VAR>variable</VAR> is a precious variable,
|
|
and include its <VAR>description</VAR> in the
|
|
variable section of <samp>./configure --help</samp>.</P><P>
|
|
|
|
Being precious means that <UL> <LI>
|
|
<VAR>variable</VAR> is substituted via
|
|
<CODE>AC_SUBST</CODE>.</P><P>
|
|
|
|
<LI> The value of <VAR>variable</VAR> when
|
|
<CODE>configure</CODE> was launched is saved in the
|
|
cache, including if it was not specified on the command line but
|
|
via the environment. Indeed, while
|
|
<CODE>configure</CODE> can notice the definition of
|
|
<CODE>CC</CODE> in <samp>./configure
|
|
CC=bizarre-cc</samp>, it is impossible to notice it in
|
|
<samp>CC=bizarre-cc ./configure</samp>, which,
|
|
unfortunately, is what most users do.</P><P>
|
|
|
|
We emphasize that it is the <EM>initial</EM> value
|
|
of <VAR>variable</VAR> which is saved, not that
|
|
found during the execution of
|
|
<CODE>configure</CODE>. Indeed, specifying
|
|
<samp>./configure FOO=foo</samp> and letting
|
|
<samp>./configure</samp> guess that
|
|
<CODE>FOO</CODE> is <CODE>foo</CODE> can
|
|
be two different things.</P><P>
|
|
|
|
<LI> <VAR>variable</VAR> is checked for
|
|
consistency between two <CODE>configure</CODE> runs.
|
|
For instance:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> $ <KBD>./configure --silent
|
|
--config-cache</KBD> $ <KBD>CC=cc ./configure
|
|
--silent --config-cache</KBD> configure: error: `CC' was
|
|
not set in the previous run configure: error: changes in the
|
|
environment can compromise \ the build configure: error: run
|
|
`make distclean' and/or \ `rm config.cache' and start over
|
|
</pre></td></tr></table></P><P>
|
|
|
|
and similarly if the variable is unset, or if its content is
|
|
changed. If the content has white space changes only, then the
|
|
error is degraded to a warning only, but the old value is
|
|
reused.</P><P>
|
|
|
|
<LI> <VAR>variable</VAR> is kept during
|
|
automatic reconfiguration (config.status Invocation) as if it
|
|
had been passed as a command line argument, including when no
|
|
cache is used:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> $ <KBD>CC=/usr/bin/cc
|
|
./configure var=raboof --silent</KBD> $
|
|
<KBD>./config.status --recheck</KBD> running
|
|
CONFIG_SHELL=/bin/sh /bin/sh ./configure var=raboof \
|
|
CC=/usr/bin/cc --no-create --no-recursion
|
|
</pre></td></tr></table> </UL>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CACHE_VAL">
|
|
<prototype>
|
|
<parameter content="cache-id"/>
|
|
<parameter content="commands-to-set-it"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Ensure that the results of the check identified by
|
|
<VAR>cache-id</VAR> are available. If the results
|
|
of the check were in the cache file that was read, and
|
|
<CODE>configure</CODE> was not given the
|
|
<samp>--quiet</samp> or
|
|
<samp>--silent</samp> option, print a message saying
|
|
that the result was cached; otherwise, run the shell commands
|
|
<VAR>commands-to-set-it</VAR>. If the shell
|
|
commands are run to determine the value, the value is saved in
|
|
the cache file just before <CODE>configure</CODE>
|
|
creates its output files. , for how to choose the name of the
|
|
<VAR>cache-id</VAR> variable.</P><P>
|
|
|
|
The <VAR>commands-to-set-it</VAR> <EM>must
|
|
have no side effects</EM> except for setting the variable
|
|
<VAR>cache-id</VAR>, see below.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CACHE_CHECK">
|
|
<prototype>
|
|
<parameter content="message"/>
|
|
<parameter content="cache-id"/>
|
|
<parameter content="@ commands-to-set-it"/>
|
|
</prototype>
|
|
<synopsis>
|
|
A wrapper for <CODE>AC_CACHE_VAL</CODE> that takes
|
|
care of printing the messages. This macro provides a convenient
|
|
shorthand for the most common way to use these macros. It calls
|
|
<CODE>AC_MSG_CHECKING</CODE> for
|
|
<VAR>message</VAR>, then
|
|
<CODE>AC_CACHE_VAL</CODE> with the
|
|
<VAR>cache-id</VAR> and
|
|
<VAR>commands</VAR> arguments, and
|
|
<CODE>AC_MSG_RESULT</CODE> with
|
|
<VAR>cache-id</VAR>.</P><P>
|
|
|
|
The <VAR>commands-to-set-it</VAR> <EM>must
|
|
have no side effects</EM> except for setting the variable
|
|
<VAR>cache-id</VAR>, see below.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CACHE_LOAD">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Loads values from existing cache file, or creates a new cache
|
|
file if a cache file is not found. Called automatically from
|
|
<CODE>AC_INIT</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CACHE_SAVE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Flushes all cached values to the cache file. Called
|
|
automatically from <CODE>AC_OUTPUT</CODE>, but it
|
|
can be quite useful to call
|
|
<CODE>AC_CACHE_SAVE</CODE> at key points in
|
|
<TT>configure.ac</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MSG_CHECKING">
|
|
<prototype>
|
|
<parameter content="feature-description"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Notify the user that <CODE>configure</CODE> is
|
|
checking for a particular feature. This macro prints a message
|
|
that starts with <samp>checking </samp> and ends
|
|
with <samp>...</samp> and no newline. It must be
|
|
followed by a call to <CODE>AC_MSG_RESULT</CODE> to
|
|
print the result of the check and the newline. The
|
|
<VAR>feature-description</VAR> should be something
|
|
like <samp>whether the Fortran compiler accepts C++
|
|
comments</samp> or <samp>for c89</samp>.</P><P>
|
|
|
|
This macro prints nothing if <CODE>configure</CODE>
|
|
is run with the <samp>--quiet</samp> or
|
|
<samp>--silent</samp> option.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MSG_RESULT">
|
|
<prototype>
|
|
<parameter content="result-description"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Notify the user of the results of a check.
|
|
<VAR>result-description</VAR> is almost always the
|
|
value of the cache variable for the check, typically
|
|
<samp>yes</samp>, <samp>no</samp>, or a
|
|
file name. This macro should follow a call to
|
|
<CODE>AC_MSG_CHECKING</CODE>, and the
|
|
<VAR>result-description</VAR> should be the
|
|
completion of the message printed by the call to
|
|
<CODE>AC_MSG_CHECKING</CODE>.</P><P>
|
|
|
|
This macro prints nothing if <CODE>configure</CODE>
|
|
is run with the <samp>--quiet</samp> or
|
|
<samp>--silent</samp> option.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MSG_NOTICE">
|
|
<prototype>
|
|
<parameter content="message"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Deliver the <VAR>message</VAR> to the user. It is
|
|
useful mainly to print a general description of the overall
|
|
purpose of a group of feature checks, e.g.,</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_MSG_NOTICE([checking if stack
|
|
overflow is detectable])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro prints nothing if <CODE>configure</CODE>
|
|
is run with the <samp>--quiet</samp> or
|
|
<samp>--silent</samp> option.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MSG_ERROR">
|
|
<prototype>
|
|
<parameter content="error-description"/>
|
|
<parameter content="[exit-status= $?/1]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Notify the user of an error that prevents
|
|
<CODE>configure</CODE> from completing. This macro
|
|
prints an error message to the standard error output and exits
|
|
<CODE>configure</CODE> with
|
|
<VAR>exit-status</VAR> (<samp>$?</samp>
|
|
by default, except that <samp>0</samp> is converted
|
|
to <samp>1</samp>).
|
|
<VAR>error-description</VAR> should be something
|
|
like <samp>invalid value $HOME for \$HOME</samp>.</P><P>
|
|
|
|
The <VAR>error-description</VAR> should start with a
|
|
lower-case letter, and ``cannot'' is preferred to ``can't''.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MSG_FAILURE">
|
|
<prototype>
|
|
<parameter content="error-description"/>
|
|
<parameter content="[exit-status]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This <CODE>AC_MSG_ERROR</CODE> wrapper notifies the
|
|
user of an error that prevents
|
|
<CODE>configure</CODE> from completing
|
|
<EM>and</EM> that additional details are provided in
|
|
<TT>config.log</TT>. This is typically used when
|
|
abnormal results are found during a compilation.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MSG_WARN">
|
|
<prototype>
|
|
<parameter content="problem-description"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Notify the <CODE>configure</CODE> user of a
|
|
possible problem. This macro prints the message to the standard
|
|
error output; <CODE>configure</CODE> continues
|
|
running afterward, so macros that call
|
|
<CODE>AC_MSG_WARN</CODE> should provide a default
|
|
(back-up) behavior for the situations they warn about.
|
|
<VAR>problem-description</VAR> should be something
|
|
like <samp>ln -s seems to make hard links</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="__file__">
|
|
<prototype>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
All M4 macros starting with <samp>__</samp> retain
|
|
their original name: for example, no
|
|
<CODE>m4__file__</CODE> is defined.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="__oline__">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This is not technically a macro, but a feature of Autom4te.
|
|
The sequence <CODE>__oline__</CODE> can be used
|
|
similarly to the other m4sugar location macros, but rather than
|
|
expanding to the location of the input file, it is translated to
|
|
the line number where it appears in the output file after all
|
|
other M4 expansions.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="dnl">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro kept its original name: no
|
|
<CODE>m4_dnl</CODE> is defined.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_bpatsubst">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="regexp"/>
|
|
<parameter content="[replacement]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro corresponds to <CODE>patsubst</CODE>.
|
|
The name <CODE>m4_patsubst</CODE> is kept for future
|
|
versions of M4sugar, once GNU M4 2.0 is released and supports
|
|
extended regular expression syntax.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_bregexp">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="regexp"/>
|
|
<parameter content="[replacement]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro corresponds to <CODE>regexp</CODE>. The
|
|
name <CODE>m4_regexp</CODE> is kept for future
|
|
versions of M4sugar, once GNU M4 2.0 is released and supports
|
|
extended regular expression syntax.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_copy">
|
|
<prototype>
|
|
<parameter content="source"/>
|
|
<parameter content="dest"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="source"/>
|
|
<parameter content="dest"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="source"/>
|
|
<parameter content="dest"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="source"/>
|
|
<parameter content="dest"/>
|
|
</prototype>
|
|
<synopsis>
|
|
These macros aren't directly builtins, but are closely
|
|
related to <CODE>m4_pushdef</CODE> and
|
|
<CODE>m4_defn</CODE>.
|
|
<CODE>m4_copy</CODE> and
|
|
<CODE>m4_rename</CODE> ensure that
|
|
<VAR>dest</VAR> is undefined, while
|
|
<CODE>m4_copy_force</CODE> and
|
|
<CODE>m4_rename_force</CODE> overwrite any existing
|
|
definition. All four macros then proceed to copy the entire
|
|
pushdef stack of definitions of <VAR>source</VAR>
|
|
over to <VAR>dest</VAR>.
|
|
<CODE>m4_copy</CODE> and
|
|
<CODE>m4_copy_force</CODE> preserve the source
|
|
(including in the special case where
|
|
<VAR>source</VAR> is undefined), while
|
|
<CODE>m4_rename</CODE> and
|
|
<CODE>m4_rename_force</CODE> undefine the original
|
|
macro name (making it an error to rename an undefined
|
|
<VAR>source</VAR>).</P><P>
|
|
|
|
Note that attempting to invoke a renamed macro might not work,
|
|
since the macro may have a dependence on helper macros accessed
|
|
via composition of <samp>$0</samp> but that were not
|
|
also renamed; likewise, other macros may have a hard-coded
|
|
dependence on <VAR>source</VAR> and could break if
|
|
<VAR>source</VAR> has been deleted. On the other
|
|
hand, it is always safe to rename a macro to temporarily move it
|
|
out of the way, then rename it back later to restore original
|
|
semantics.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_defn">
|
|
<prototype>
|
|
<parameter content="macro..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro fails if <VAR>macro</VAR> is not
|
|
defined, even when using older versions of M4 that did not warn.
|
|
See <CODE>m4_undefine</CODE>. Unfortunately, in
|
|
order to support these older versions of M4, there are some
|
|
situations involving unbalanced quotes where concatenating
|
|
multiple macros together will work in newer M4 but not in
|
|
m4sugar; use quadrigraphs to work around this.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_divert">
|
|
<prototype>
|
|
<parameter content="diversion"/>
|
|
</prototype>
|
|
<synopsis>
|
|
M4sugar relies heavily on diversions, so rather than behaving
|
|
as a primitive, <CODE>m4_divert</CODE> behaves like:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_divert_pop()m4_divert_push([<VAR>diversion</VAR>])
|
|
</pre></td></tr></table> , for more
|
|
details about the use of the diversion stack. In particular,
|
|
this implies that <VAR>diversion</VAR> should be a
|
|
named diversion rather than a raw number. But be aware that it
|
|
is seldom necessary to explicitly change the diversion stack,
|
|
and that when done incorrectly, it can lead to syntactically
|
|
invalid scripts.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_dumpdef">
|
|
<prototype>
|
|
<parameter content="name..."/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="name..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
<CODE>m4_dumpdef</CODE> is like the M4 builtin,
|
|
except that this version requires at least one argument, output
|
|
always goes to standard error rather than the current debug
|
|
file, no sorting is done on multiple arguments, and an error is
|
|
issued if any <VAR>name</VAR> is undefined.
|
|
<CODE>m4_dumpdefs</CODE> is a convenience macro that
|
|
calls <CODE>m4_dumpdef</CODE> for all of the
|
|
<CODE>m4_pushdef</CODE> stack of definitions,
|
|
starting with the current, and silently does nothing if
|
|
<VAR>name</VAR> is undefined.</P><P>
|
|
|
|
Unfortunately, due to a limitation in M4 1.4.x, any macro
|
|
defined as a builtin is output as the empty string. This
|
|
behavior is rectified by using M4 1.6 or newer. However, this
|
|
behavior difference means that
|
|
<CODE>m4_dumpdef</CODE> should only be used while
|
|
developing m4sugar macros, and never in the final published form
|
|
of a macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_esyscmd_s">
|
|
<prototype>
|
|
<parameter content="command"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like <CODE>m4_esyscmd</CODE>, this macro expands to
|
|
the result of running <VAR>command</VAR> in a shell.
|
|
The difference is that any trailing newlines are removed, so
|
|
that the output behaves more like shell command substitution.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_exit">
|
|
<prototype>
|
|
<parameter content="exit-status"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro corresponds to <CODE>m4exit</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_if">
|
|
<prototype>
|
|
<parameter content="comment"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="string-1"/>
|
|
<parameter content="string-2"/>
|
|
<parameter content="equal"/>
|
|
<parameter content="[not-equal]"/>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
<VAR>string-3</VAR>,
|
|
<VAR>string-4</VAR>, <VAR>equal-2</VAR>,
|
|
<small>...</small>, not-equal) This macro
|
|
corresponds to <CODE>ifelse</CODE>.
|
|
<VAR>string-1</VAR> and
|
|
<VAR>string-2</VAR> are compared literally, so
|
|
usually one of the two arguments is passed unquoted. , for more
|
|
conditional idioms.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_include">
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Like the M4 builtins, but warn against multiple inclusions of
|
|
<VAR>file</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_mkstemp">
|
|
<prototype>
|
|
<parameter content="template"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="template"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Posix requires <CODE>maketemp</CODE> to replace
|
|
the trailing <samp>X</samp> characters in
|
|
<VAR>template</VAR> with the process id, without
|
|
regards to the existence of a file by that name, but this a
|
|
security hole. When this was pointed out to the Posix folks,
|
|
they agreed to invent a new macro
|
|
<CODE>mkstemp</CODE> that always creates a uniquely
|
|
named file, but not all versions of GNU M4 support the new
|
|
macro. In M4sugar, <CODE>m4_maketemp</CODE> and
|
|
<CODE>m4_mkstemp</CODE> are synonyms for each other,
|
|
and both have the secure semantics regardless of which macro the
|
|
underlying M4 provides.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_popdef">
|
|
<prototype>
|
|
<parameter content="macro..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro fails if <VAR>macro</VAR> is not
|
|
defined, even when using older versions of M4 that did not warn.
|
|
See <CODE>m4_undefine</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_undefine">
|
|
<prototype>
|
|
<parameter content="macro..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro fails if <VAR>macro</VAR> is not
|
|
defined, even when using older versions of M4 that did not warn.
|
|
Use</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_ifdef([<VAR>macro</VAR>],
|
|
[m4_undefine([<VAR>macro</VAR>])])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
if you are not sure whether <VAR>macro</VAR> is
|
|
defined.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_undivert">
|
|
<prototype>
|
|
<parameter content="diversion..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Unlike the M4 builtin, at least one
|
|
<VAR>diversion</VAR> must be specified. Also, since
|
|
the M4sugar diversion stack prefers named diversions, the use of
|
|
<CODE>m4_undivert</CODE> to include files is risky.
|
|
, for more details about the use of the diversion stack. But be
|
|
aware that it is seldom necessary to explicitly change the
|
|
diversion stack, and that when done incorrectly, it can lead to
|
|
syntactically invalid scripts.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_wrap">
|
|
<prototype>
|
|
<parameter content="text"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="text"/>
|
|
</prototype>
|
|
<synopsis>
|
|
These macros correspond to <CODE>m4wrap</CODE>.
|
|
Posix requires arguments of multiple wrap calls to be
|
|
reprocessed at EOF in the same order as the original calls
|
|
(first-in, first-out). GNU M4 versions through 1.4.10, however,
|
|
reprocess them in reverse order (last-in, first-out). Both
|
|
orders are useful, therefore, you can rely on
|
|
<CODE>m4_wrap</CODE> to provide FIFO semantics and
|
|
<CODE>m4_wrap_lifo</CODE> for LIFO semantics,
|
|
regardless of the underlying GNU M4 version.</P><P>
|
|
|
|
Unlike the GNU M4 builtin, these macros only recognize one
|
|
argument, and avoid token pasting between consecutive
|
|
invocations. On the other hand, nested calls to
|
|
<CODE>m4_wrap</CODE> from within wrapped text work
|
|
just as in the builtin.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_assert">
|
|
<prototype>
|
|
<parameter content="expression"/>
|
|
<parameter content="[exit-status= 1]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Assert that the arithmetic <VAR>expression</VAR>
|
|
evaluates to non-zero. Otherwise, issue a fatal error, and exit
|
|
<CODE>autom4te</CODE> with
|
|
<VAR>exit-status</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_errprintn">
|
|
<prototype>
|
|
<parameter content="message"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Similar to the builtin <CODE>m4_errprint</CODE>,
|
|
except that a newline is guaranteed after
|
|
<VAR>message</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_fatal">
|
|
<prototype>
|
|
<parameter content="message"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Report a severe error <VAR>message</VAR> prefixed
|
|
with the current location, and have
|
|
<CODE>autom4te</CODE> die.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_location">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Useful as a prefix in a message line. Short for:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> __file__:__line__
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_warn">
|
|
<prototype>
|
|
<parameter content="category"/>
|
|
<parameter content="message"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Report <VAR>message</VAR> as a warning (or as an
|
|
error if requested by the user) if warnings of the
|
|
<VAR>category</VAR> are turned on. If the message
|
|
is emitted, it is prefixed with the current location, and
|
|
followed by a call trace of all macros defined via
|
|
<CODE>AC_DEFUN</CODE> used to get to the current
|
|
expansion. You are encouraged to use standard categories, which
|
|
currently include:</P><P>
|
|
|
|
<DL> <DT>'<SAMP>all</SAMP>' <DD>
|
|
messages that don't fall into one of the following categories.
|
|
Use of an empty <VAR>category</VAR> is equivalent.</P><P>
|
|
|
|
<DT>'<SAMP>cross</SAMP>' <DD> related to
|
|
cross compilation issues.</P><P>
|
|
|
|
<DT>'<SAMP>obsolete</SAMP>' <DD> use of
|
|
an obsolete construct.</P><P>
|
|
|
|
<DT>'<SAMP>syntax</SAMP>' <DD> dubious
|
|
syntactic constructs, incorrectly ordered macro calls.
|
|
</DL>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_cleardivert">
|
|
<prototype>
|
|
<parameter content="diversion..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Permanently discard any text that has been diverted into
|
|
<VAR>diversion</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_divert_once">
|
|
<prototype>
|
|
<parameter content="diversion"/>
|
|
<parameter content="[content]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Similar to <CODE>m4_divert_text</CODE>, except that
|
|
<VAR>content</VAR> is only output to
|
|
<VAR>diversion</VAR> if this is the first time that
|
|
<CODE>m4_divert_once</CODE> has been called with its
|
|
particular arguments.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_divert_pop">
|
|
<prototype>
|
|
<parameter content="[diversion]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If provided, check that the current diversion is indeed
|
|
<VAR>diversion</VAR>. Then change to the diversion
|
|
located earlier on the stack, giving an error if an attempt is
|
|
made to pop beyond the initial m4sugar diversion of
|
|
<CODE>KILL</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_divert_push">
|
|
<prototype>
|
|
<parameter content="diversion"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Remember the former diversion on the diversion stack, and
|
|
output subsequent text into <VAR>diversion</VAR>.
|
|
M4sugar maintains a diversion stack, and issues an error if
|
|
there is not a matching pop for every push.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_divert_text">
|
|
<prototype>
|
|
<parameter content="diversion"/>
|
|
<parameter content="[content]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Output <VAR>content</VAR> and a newline into
|
|
<VAR>diversion</VAR>, without affecting the current
|
|
diversion. Shorthand for:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_divert_push([<VAR>diversion</VAR>])<VAR>content</VAR>
|
|
m4_divert_pop([<VAR>diversion</VAR>])dnl
|
|
</pre></td></tr></table></P><P>
|
|
|
|
One use of <CODE>m4_divert_text</CODE> is to develop
|
|
two related macros, where macro <samp>MY_A</samp>
|
|
does the work, but adjusts what work is performed based on
|
|
whether the optional macro <samp>MY_B</samp> has
|
|
also been expanded. Of course, it is possible to use
|
|
<CODE>AC_BEFORE</CODE> within
|
|
<CODE>MY_A</CODE> to require that
|
|
<samp>MY_B</samp> occurs first, if it occurs at all.
|
|
But this imposes an ordering restriction on the user; it would
|
|
be nicer if macros <samp>MY_A</samp> and
|
|
<samp>MY_B</samp> can be invoked in either order.
|
|
The trick is to let <samp>MY_B</samp> leave a
|
|
breadcrumb in an early diversion, which
|
|
<samp>MY_A</samp> can then use to determine whether
|
|
<samp>MY_B</samp> has been expanded.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_DEFUN([MY_A], [# various actions
|
|
if test -n "$b_was_used"; then # extra action fi])
|
|
AC_DEFUN([MY_B], [AC_REQUIRE([MY_A])dnl
|
|
m4_divert_text([INIT_PREPARE], [b_was_used=true])])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_init">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Initialize the M4sugar environment, setting up the default
|
|
named diversion to be <CODE>KILL</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_bmatch">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="regex-1"/>
|
|
<parameter content="value-1"/>
|
|
<parameter content="@ [regex-2]"/>
|
|
<parameter content="[value-2]"/>
|
|
<parameter content="..."/>
|
|
<parameter content="[default]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
The string <VAR>string</VAR> is repeatedly compared
|
|
against a series of <VAR>regex</VAR> arguments; if a
|
|
match is found, the expansion is the corresponding
|
|
<VAR>value</VAR>, otherwise, the macro moves on to
|
|
the next <VAR>regex</VAR>. If no
|
|
<VAR>regex</VAR> match, then the result is the
|
|
optional <VAR>default</VAR>, or nothing.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_bpatsubsts">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="regex-1"/>
|
|
<parameter content="subst-1"/>
|
|
<parameter content="@ [regex-2]"/>
|
|
<parameter content="[subst-2]"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
The string <VAR>string</VAR> is altered by
|
|
<VAR>regex-1</VAR> and
|
|
<VAR>subst-1</VAR>, as if by:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_bpatsubst([[<VAR>string</VAR>]],
|
|
[<VAR>regex</VAR>], [<VAR>subst</VAR>])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The result of the substitution is then passed through the next
|
|
set of <VAR>regex</VAR> and
|
|
<VAR>subst</VAR>, and so forth. An empty
|
|
<VAR>subst</VAR> implies deletion of any matched
|
|
portions in the current string. Note that this macro
|
|
over-quotes <VAR>string</VAR>; this behavior is
|
|
intentional, so that the result of each step of the recursion
|
|
remains as a quoted string. However, it means that anchors
|
|
(<samp>^</samp> and <samp>$</samp> in
|
|
the <VAR>regex</VAR> will line up with the extra
|
|
quotations, and not the characters of the original string. The
|
|
overquoting is removed after the final substitution.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_case">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="value-1"/>
|
|
<parameter content="if-value-1"/>
|
|
<parameter content="@ [value-2]"/>
|
|
<parameter content="[if-value-2]"/>
|
|
<parameter content="..."/>
|
|
<parameter content="[default]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Test <VAR>string</VAR> against multiple
|
|
<VAR>value</VAR> possibilities, resulting in the
|
|
first <VAR>if-value</VAR> for a match, or in the
|
|
optional <VAR>default</VAR>. This is shorthand for:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_if([<VAR>string</VAR>],
|
|
[<VAR>value-1</VAR>],
|
|
[<VAR>if-value-1</VAR>],
|
|
[<VAR>string</VAR>],
|
|
[<VAR>value-2</VAR>],
|
|
[<VAR>if-value-2</VAR>],
|
|
<small>...</small>,
|
|
[<VAR>default</VAR>])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_cond">
|
|
<prototype>
|
|
<parameter content="test-1"/>
|
|
<parameter content="value-1"/>
|
|
<parameter content="if-value-1"/>
|
|
<parameter content="@ [test-2]"/>
|
|
<parameter content="[value-2]"/>
|
|
<parameter content="[if-value-2]"/>
|
|
<parameter content="..."/>
|
|
<parameter content="[default]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62. Similar to
|
|
<CODE>m4_if</CODE>, except that each
|
|
<VAR>test</VAR> is expanded only when it is
|
|
encountered. This is useful for short-circuiting expensive
|
|
tests; while <CODE>m4_if</CODE> requires all its
|
|
strings to be expanded up front before doing comparisons,
|
|
<CODE>m4_cond</CODE> only expands a
|
|
<VAR>test</VAR> when all earlier tests have failed.</P><P>
|
|
|
|
For an example, these two sequences give the same result, but in
|
|
the case where <samp>$1</samp> does not contain a
|
|
backslash, the <CODE>m4_cond</CODE> version only
|
|
expands <CODE>m4_index</CODE> once, instead of five
|
|
times, for faster computation if this is a common case for
|
|
<samp>$1</samp>. Notice that every third argument
|
|
is unquoted for <CODE>m4_if</CODE>, and quoted for
|
|
<CODE>m4_cond</CODE>:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_if(m4_index([$1], [\]), [-1],
|
|
[$2], m4_eval(m4_index([$1], [\\]) >= 0), [1], [$2],
|
|
m4_eval(m4_index([$1], [\$]) >= 0), [1], [$2],
|
|
m4_eval(m4_index([$1], [\`]) >= 0), [1], [$3],
|
|
m4_eval(m4_index([$1], [\"]) >= 0), [1], [$3], [$2])
|
|
m4_cond([m4_index([$1], [\])], [-1], [$2],
|
|
[m4_eval(m4_index([$1], [\\]) >= 0)], [1], [$2],
|
|
[m4_eval(m4_index([$1], [\$]) >= 0)], [1], [$2],
|
|
[m4_eval(m4_index([$1], [\`]) >= 0)], [1], [$3],
|
|
[m4_eval(m4_index([$1], [\"]) >= 0)], [1], [$3],
|
|
[$2]) </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_default">
|
|
<prototype>
|
|
<parameter content="expr-1"/>
|
|
<parameter content="expr-2"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="expr-1"/>
|
|
<parameter content="expr-2"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="expr-1"/>
|
|
<parameter content="[expr-2]"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="expr-1"/>
|
|
<parameter content="[expr-2]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If <VAR>expr-1</VAR> contains text, use it.
|
|
Otherwise, select <VAR>expr-2</VAR>.
|
|
<CODE>m4_default</CODE> expands the result, while
|
|
<CODE>m4_default_quoted</CODE> does not. Useful for
|
|
providing a fixed default if the expression that results in
|
|
<VAR>expr-1</VAR> would otherwise be empty. The
|
|
difference between <CODE>m4_default</CODE> and
|
|
<CODE>m4_default_nblank</CODE> is whether an
|
|
argument consisting of just blanks (space, tab, newline) is
|
|
significant. When using the expanding versions, note that an
|
|
argument may contain text but still expand to an empty string.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([active], [ACTIVE])dnl
|
|
m4_define([empty], [])dnl m4_define([demo1], [m4_default([$1],
|
|
[$2])])dnl m4_define([demo2], [m4_default_quoted([$1],
|
|
[$2])])dnl m4_define([demo3], [m4_default_nblank([$1],
|
|
[$2])])dnl m4_define([demo4], [m4_default_nblank_quoted([$1],
|
|
[$2])])dnl demo1([active], [default]) ACTIVE demo1([], [active])
|
|
ACTIVE demo1([empty], [text]) -demo1([ ], [active])- - -
|
|
demo2([active], [default]) active demo2([], [active]) active
|
|
demo2([empty], [text]) empty -demo2([ ], [active])- - -
|
|
demo3([active], [default]) ACTIVE demo3([], [active]) ACTIVE
|
|
demo3([empty], [text]) -demo3([ ], [active])- -ACTIVE-
|
|
demo4([active], [default]) active demo4([], [active]) active
|
|
demo4([empty], [text]) empty -demo4([ ], [active])- -active-
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_define_default">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="[default-definition]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If <VAR>macro</VAR> does not already have a
|
|
definition, then define it to
|
|
<VAR>default-definition</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_ifblank">
|
|
<prototype>
|
|
<parameter content="cond"/>
|
|
<parameter content="[if-blank]"/>
|
|
<parameter content="[if-text]"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="cond"/>
|
|
<parameter content="[if-text]"/>
|
|
<parameter content="[if-blank]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If <VAR>cond</VAR> is empty or consists only of
|
|
blanks (space, tab, newline), then expand
|
|
<VAR>if-blank</VAR>; otherwise, expand
|
|
<VAR>if-text</VAR>. Two variants exist, in order to
|
|
make it easier to select the correct logical sense when using
|
|
only two parameters. Note that this is more efficient than the
|
|
equivalent behavior of:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_ifval(m4_normalize([<VAR>cond</VAR>]),
|
|
<VAR>if-text</VAR>, <VAR>if-blank</VAR>)
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_ifndef">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="if-not-defined"/>
|
|
<parameter content="[if-defined]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This is shorthand for:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_ifdef([<VAR>macro</VAR>],
|
|
[<VAR>if-defined</VAR>],
|
|
[<VAR>if-not-defined</VAR>])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_ifset">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="[if-true]"/>
|
|
<parameter content="[if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If <VAR>macro</VAR> is undefined, or is defined as
|
|
the empty string, expand to <VAR>if-false</VAR>.
|
|
Otherwise, expands to <VAR>if-true</VAR>. Similar
|
|
to: <TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_ifval(m4_defn([<VAR>macro</VAR>]),
|
|
[<VAR>if-true</VAR>],
|
|
[<VAR>if-false</VAR>])
|
|
</pre></td></tr></table> except that it
|
|
is not an error if <VAR>macro</VAR> is undefined.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_ifval">
|
|
<prototype>
|
|
<parameter content="cond"/>
|
|
<parameter content="[if-true]"/>
|
|
<parameter content="[if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands to <VAR>if-true</VAR> if
|
|
<VAR>cond</VAR> is not empty, otherwise to
|
|
<VAR>if-false</VAR>. This is shorthand for:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_if([<VAR>cond</VAR>], [],
|
|
[<VAR>if-true</VAR>],
|
|
[<VAR>if-false</VAR>])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_ifvaln">
|
|
<prototype>
|
|
<parameter content="cond"/>
|
|
<parameter content="[if-true]"/>
|
|
<parameter content="[if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Similar to <CODE>m4_ifval</CODE>, except guarantee
|
|
that a newline is present after any non-empty expansion. Often
|
|
followed by <CODE>dnl</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_n">
|
|
<prototype>
|
|
<parameter content="text"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand to <VAR>text</VAR>, and add a newline if
|
|
<VAR>text</VAR> is not empty. Often followed by
|
|
<CODE>dnl</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_argn">
|
|
<prototype>
|
|
<parameter content="n"/>
|
|
<parameter content="[arg]..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Extracts argument <VAR>n</VAR> (larger than 0) from
|
|
the remaining arguments. If there are too few arguments, the
|
|
empty string is used. For any <VAR>n</VAR> besides
|
|
1, this is more efficient than the similar
|
|
<samp>m4_car(m4_shiftn([<VAR>n</VAR>], [],
|
|
[<VAR>arg</VAR><small>...</small>]))</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_car">
|
|
<prototype>
|
|
<parameter content="arg..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands to the quoted first <VAR>arg</VAR>. Can be
|
|
used with <CODE>m4_cdr</CODE> to recursively iterate
|
|
through a list. Generally, when using quoted lists of quoted
|
|
elements, <CODE>m4_car</CODE> should be called
|
|
without any extra quotes.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_cdr">
|
|
<prototype>
|
|
<parameter content="arg..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands to a quoted list of all but the first
|
|
<VAR>arg</VAR>, or the empty string if there was
|
|
only one argument. Generally, when using quoted lists of quoted
|
|
elements, <CODE>m4_cdr</CODE> should be called
|
|
without any extra quotes.</P><P>
|
|
|
|
For example, this is a simple implementation of
|
|
<CODE>m4_map</CODE>; note how each iteration checks
|
|
for the end of recursion, then merely applies the first argument
|
|
to the first element of the list, then repeats with the rest of
|
|
the list. (The actual implementation in M4sugar is a bit more
|
|
involved, to gain some speed and share code with
|
|
<CODE>m4_map_sep</CODE>, and also to avoid expanding
|
|
side effects in <samp>$2</samp> twice).
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([m4_map], [m4_ifval([$2],
|
|
[m4_apply([$1], m4_car($2))[]$0([$1], m4_cdr($2))])])dnl
|
|
m4_map([ m4_eval], [[[1]], [[1+1]], [[10],[16]]]) 1 2 a
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_for">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="first"/>
|
|
<parameter content="last"/>
|
|
<parameter content="[step]"/>
|
|
<parameter content="@ expression"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Loop over the numeric values between
|
|
<VAR>first</VAR> and <VAR>last</VAR>
|
|
including bounds by increments of <VAR>step</VAR>.
|
|
For each iteration, expand <VAR>expression</VAR>
|
|
with the numeric value assigned to <VAR>var</VAR>.
|
|
If <VAR>step</VAR> is omitted, it defaults to
|
|
<samp>1</samp> or <samp>-1</samp>
|
|
depending on the order of the limits. If given,
|
|
<VAR>step</VAR> has to match this order. The number
|
|
of iterations is determined independently from definition of
|
|
<VAR>var</VAR>; iteration cannot be short-circuited
|
|
or lengthened by modifying <VAR>var</VAR> from
|
|
within <VAR>expression</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_foreach">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="list"/>
|
|
<parameter content="expression"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Loop over the comma-separated M4 list
|
|
<VAR>list</VAR>, assigning each value to
|
|
<VAR>var</VAR>, and expand
|
|
<VAR>expression</VAR>. The following example
|
|
outputs two lines:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_foreach([myvar], [[foo], [bar,
|
|
baz]], [echo myvar ])dnl echo foo echo bar, baz
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Note that for some forms of <VAR>expression</VAR>,
|
|
it may be faster to use <CODE>m4_map_args</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_foreach_w">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="list"/>
|
|
<parameter content="expression"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Loop over the white-space-separated list
|
|
<VAR>list</VAR>, assigning each value to
|
|
<VAR>var</VAR>, and expand
|
|
<VAR>expression</VAR>. If
|
|
<VAR>var</VAR> is only referenced once in
|
|
<VAR>expression</VAR>, it is more efficient to use
|
|
<CODE>m4_map_args_w</CODE>.</P><P>
|
|
|
|
The deprecated macro <CODE>AC_FOREACH</CODE> is an
|
|
alias of <CODE>m4_foreach_w</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_map">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="list"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="list"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="separator"/>
|
|
<parameter content="list"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="separator"/>
|
|
<parameter content="list"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Loop over the comma separated quoted list of argument
|
|
descriptions in <VAR>list</VAR>, and invoke
|
|
<VAR>macro</VAR> with the arguments. An argument
|
|
description is in turn a comma-separated quoted list of quoted
|
|
elements, suitable for <CODE>m4_apply</CODE>. The
|
|
macros <CODE>m4_map</CODE> and
|
|
<CODE>m4_map_sep</CODE> ignore empty argument
|
|
descriptions, while <CODE>m4_mapall</CODE> and
|
|
<CODE>m4_mapall_sep</CODE> invoke
|
|
<VAR>macro</VAR> with no arguments. The macros
|
|
<CODE>m4_map_sep</CODE> and
|
|
<CODE>m4_mapall_sep</CODE> additionally expand
|
|
<VAR>separator</VAR> between invocations of
|
|
<VAR>macro</VAR>.</P><P>
|
|
|
|
Note that <VAR>separator</VAR> is expanded, unlike
|
|
in <CODE>m4_join</CODE>. When separating output
|
|
with commas, this means that the map result can be used as a
|
|
series of arguments, by using a single-quoted comma as
|
|
<VAR>separator</VAR>, or as a single string, by
|
|
using a double-quoted comma.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_map([m4_count], []) m4_map([
|
|
m4_count], [[], [[1]],
|
|
[[1], [2]]]) 1 2 m4_mapall([ m4_count], [[],
|
|
[[1]], [[1], [2]]]) 0 1 2
|
|
m4_map_sep([m4_eval], [,], [[[1+2]],
|
|
[[10], [16]]]) 3,a m4_map_sep([m4_echo], [,], [[[a]], [[b]]])
|
|
a,b m4_count(m4_map_sep([m4_echo], [,], [[[a]], [[b]]])) 2
|
|
m4_map_sep([m4_echo], [[,]], [[[a]], [[b]]]) a,b
|
|
m4_count(m4_map_sep([m4_echo], [[,]], [[[a]], [[b]]])) 1
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_map_args">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="arg..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Repeatedly invoke <VAR>macro</VAR> with each
|
|
successive <VAR>arg</VAR> as its only argument. In
|
|
the following example, three solutions are presented with the
|
|
same expansion; the solution using
|
|
<CODE>m4_map_args</CODE> is the most efficient.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([active], [ACTIVE])dnl
|
|
m4_foreach([var], [[plain], [active]], [
|
|
m4_echo(m4_defn([var]))]) plain active m4_map([ m4_echo],
|
|
[[[plain]], [[active]]]) plain active m4_map_args([ m4_echo],
|
|
[plain], [active]) plain active
|
|
</pre></td></tr></table></P><P>
|
|
|
|
In cases where it is useful to operate on additional parameters
|
|
besides the list elements, the macro
|
|
<CODE>m4_curry</CODE> can be used in
|
|
<VAR>macro</VAR> to supply the argument currying
|
|
necessary to generate the desired argument list. In the
|
|
following example, <CODE>list_add_n</CODE> is more
|
|
efficient than <CODE>list_add_x</CODE>. On the
|
|
other hand, using <CODE>m4_map_args_sep</CODE> can
|
|
be even more efficient.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([list], [[1], [2],
|
|
[3]])dnl m4_define([add], [m4_eval(([$1]) + ([$2]))])dnl dnl
|
|
list_add_n(N, ARG...) dnl Output a list consisting of each ARG
|
|
added to N m4_define([list_add_n],
|
|
[m4_shift(m4_map_args([,m4_curry([add], [$1])],
|
|
m4_shift($@@)))])dnl list_add_n([1], list) 2,3,4 list_add_n([2],
|
|
list) 3,4,5 m4_define([list_add_x], [m4_shift(m4_foreach([var],
|
|
m4_dquote(m4_shift($@@)), [,add([$1],m4_defn([var]))]))])dnl
|
|
list_add_x([1], list) 2,3,4
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_map_args_pair">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="[macro-end= macro]"/>
|
|
<parameter content="@ arg..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
For every pair of arguments <VAR>arg</VAR>, invoke
|
|
<VAR>macro</VAR> with two arguments. If there is an
|
|
odd number of arguments, invoke
|
|
<VAR>macro-end</VAR>, which defaults to
|
|
<VAR>macro</VAR>, with the remaining argument.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_map_args_pair([, m4_reverse],
|
|
[], [1], [2], [3]) , 2, 1, 3 m4_map_args_pair([, m4_reverse], [,
|
|
m4_dquote], [1], [2], [3]) , 2, 1, [3] m4_map_args_pair([,
|
|
m4_reverse], [, m4_dquote], [1], [2], [3], [4]) , 2, 1, 4, 3
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_map_args_sep">
|
|
<prototype>
|
|
<parameter content="[pre]"/>
|
|
<parameter content="[post]"/>
|
|
<parameter content="[sep]"/>
|
|
<parameter content="arg..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand the sequence
|
|
<CODE><VAR>pre</VAR>[<VAR>arg</VAR>]<VAR>post</VAR></CODE>
|
|
for each argument, additionally expanding
|
|
<VAR>sep</VAR> between arguments. One common use of
|
|
this macro is constructing a macro call, where the opening and
|
|
closing parentheses are split between <VAR>pre</VAR>
|
|
and <VAR>post</VAR>; in particular,
|
|
<CODE>m4_map_args([<VAR>macro</VAR>],
|
|
[<VAR>arg</VAR>])</CODE> is equivalent to
|
|
<CODE>m4_map_args_sep([<VAR>macro</VAR>(],
|
|
[)], [], [<VAR>arg</VAR>])</CODE>. This macro
|
|
provides the most efficient means for iterating over an
|
|
arbitrary list of arguments, particularly when repeatedly
|
|
constructing a macro call with more arguments than
|
|
<VAR>arg</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_map_args_w">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="[pre]"/>
|
|
<parameter content="[post]"/>
|
|
<parameter content="[sep]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand the sequence
|
|
<CODE><VAR>pre</VAR>[word]<VAR>post</VAR></CODE>
|
|
for each word in the whitespace-separated
|
|
<VAR>string</VAR>, additionally expanding
|
|
<VAR>sep</VAR> between words. This macro provides
|
|
the most efficient means for iterating over a
|
|
whitespace-separated string. In particular,
|
|
<CODE>m4_map_args_w([<VAR>string</VAR>],
|
|
[<VAR>action</VAR>(], [)])</CODE> is more
|
|
efficient than <CODE>m4_foreach_w([var],
|
|
[<VAR>string</VAR>],
|
|
[<VAR>action</VAR>(m4_defn([var]))])</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_shiftn">
|
|
<prototype>
|
|
<parameter content="count"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
<CODE>m4_shiftn</CODE> performs
|
|
<VAR>count</VAR> iterations of
|
|
<CODE>m4_shift</CODE>, along with validation that
|
|
enough arguments were passed in to match the shift count, and
|
|
that the count is positive. <CODE>m4_shift2</CODE>
|
|
and <CODE>m4_shift3</CODE> are specializations of
|
|
<CODE>m4_shiftn</CODE>, introduced in Autoconf 2.62,
|
|
and are more efficient for two and three shifts, respectively.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_stack_foreach">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="action"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="action"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each of the <CODE>m4_pushdef</CODE>
|
|
definitions of <VAR>macro</VAR>, expand
|
|
<VAR>action</VAR> with the single argument of a
|
|
definition of <VAR>macro</VAR>.
|
|
<CODE>m4_stack_foreach</CODE> starts with the oldest
|
|
definition, while <CODE>m4_stack_foreach_lifo</CODE>
|
|
starts with the current definition.
|
|
<VAR>action</VAR> should not push or pop definitions
|
|
of <VAR>macro</VAR>, nor is there any guarantee that
|
|
the current definition of <VAR>macro</VAR> matches
|
|
the argument that was passed to <VAR>action</VAR>.
|
|
The macro <CODE>m4_curry</CODE> can be used if
|
|
<VAR>action</VAR> needs more than one argument,
|
|
although in that case it is more efficient to use
|
|
<VAR>m4_stack_foreach_sep</VAR>.</P><P>
|
|
|
|
Due to technical limitations, there are a few low-level m4sugar
|
|
functions, such as <CODE>m4_pushdef</CODE>, that
|
|
cannot be used as the <VAR>macro</VAR> argument.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_pushdef([a], [1])m4_pushdef([a],
|
|
[2])dnl m4_stack_foreach([a], [ m4_incr]) 2 3
|
|
m4_stack_foreach_lifo([a], [ m4_curry([m4_substr], [abcd])]) cd
|
|
bcd </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_stack_foreach_sep">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="[pre]"/>
|
|
<parameter content="[post]"/>
|
|
<parameter content="[sep]"/>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
sep) Expand the sequence
|
|
<CODE><VAR>pre</VAR>[definition]<VAR>post</VAR></CODE>
|
|
for each <CODE>m4_pushdef</CODE> definition of
|
|
<VAR>macro</VAR>, additionally expanding
|
|
<VAR>sep</VAR> between definitions.
|
|
<CODE>m4_stack_foreach_sep</CODE> visits the oldest
|
|
definition first, while
|
|
<CODE>m4_stack_foreach_sep_lifo</CODE> visits the
|
|
current definition first. This macro provides the most
|
|
efficient means for iterating over a pushdef stack. In
|
|
particular,
|
|
<CODE>m4_stack_foreach([<VAR>macro</VAR>],
|
|
[<VAR>action</VAR>])</CODE> is short for
|
|
<CODE>m4_stack_foreach_sep([<VAR>macro</VAR>],
|
|
[<VAR>action</VAR>(], [)])</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_apply">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="list"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Apply the elements of the quoted, comma-separated
|
|
<VAR>list</VAR> as the arguments to
|
|
<VAR>macro</VAR>. If <VAR>list</VAR> is
|
|
empty, invoke <VAR>macro</VAR> without arguments.
|
|
Note the difference between <CODE>m4_indir</CODE>,
|
|
which expects its first argument to be a macro name but can use
|
|
names that are otherwise invalid, and
|
|
<CODE>m4_apply</CODE>, where
|
|
<VAR>macro</VAR> can contain other text, but must
|
|
end in a valid macro name.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_apply([m4_count], []) 0
|
|
m4_apply([m4_count], [[]]) 1 m4_apply([m4_count], [[1], [2]]) 2
|
|
m4_apply([m4_join], [[|], [1], [2]]) 1|2
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_count">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro returns the decimal count of the number of arguments
|
|
it was passed.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_curry">
|
|
<prototype>
|
|
<parameter content="macro"/>
|
|
<parameter content="arg..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro performs argument currying. The expansion of this
|
|
macro is another macro name that expects exactly one argument;
|
|
that argument is then appended to the <VAR>arg</VAR>
|
|
list, and then <VAR>macro</VAR> is expanded with the
|
|
resulting argument list.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_curry([m4_curry], [m4_reverse],
|
|
[1])([2])([3]) 3, 2, 1
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Unfortunately, due to a limitation in M4 1.4.x, it is not
|
|
possible to pass the definition of a builtin macro as the
|
|
argument to the output of <CODE>m4_curry</CODE>; the
|
|
empty string is used instead of the builtin token. This behavior
|
|
is rectified by using M4 1.6 or newer.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_do">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro loops over its arguments and expands each
|
|
<VAR>arg</VAR> in sequence. Its main use is for
|
|
readability; it allows the use of indentation and fewer
|
|
<CODE>dnl</CODE> to result in the same expansion.
|
|
This macro guarantees that no expansion will be concatenated
|
|
with subsequent text; to achieve full concatenation, use
|
|
<CODE>m4_unquote(m4_join([],
|
|
<VAR>arg</VAR></CODE>)).</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_define([ab],[1])m4_define([bc],[2])m4_define([abc],[3])dnl
|
|
m4_do([a],[b])c abc m4_unquote(m4_join([],[a],[b]))c 3
|
|
m4_define([a],[A])m4_define([b],[B])m4_define([c],[C])dnl
|
|
m4_define([AB],[4])m4_define([BC],[5])m4_define([ABC],[6])dnl
|
|
m4_do([a],[b])c ABC m4_unquote(m4_join([],[a],[b]))c 3
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_dquote">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Return the arguments as a quoted list of quoted arguments.
|
|
Conveniently, if there is just one <VAR>arg</VAR>,
|
|
this effectively adds a level of quoting.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_dquote_elt">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Return the arguments as a series of double-quoted arguments.
|
|
Whereas <CODE>m4_dquote</CODE> returns a single
|
|
argument, <CODE>m4_dquote_elt</CODE> returns as many
|
|
arguments as it was passed.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_echo">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Return the arguments, with the same level of quoting. Other
|
|
than discarding whitespace after unquoted commas, this macro is
|
|
a no-op.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_expand">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Return the expansion of <VAR>arg</VAR> as a quoted
|
|
string. Whereas <CODE>m4_quote</CODE> is designed
|
|
to collect expanded text into a single argument,
|
|
<CODE>m4_expand</CODE> is designed to perform one
|
|
level of expansion on quoted text. One distinction is in the
|
|
treatment of whitespace following a comma in the original
|
|
<VAR>arg</VAR>. Any time multiple arguments are
|
|
collected into one with <CODE>m4_quote</CODE>, the
|
|
M4 argument collection rules discard the whitespace. However,
|
|
with <CODE>m4_expand</CODE>, whitespace is
|
|
preserved, even after the expansion of macros contained in
|
|
<VAR>arg</VAR>. Additionally,
|
|
<CODE>m4_expand</CODE> is able to expand text that
|
|
would involve an unterminated comment, whereas expanding that
|
|
same text as the argument to <CODE>m4_quote</CODE>
|
|
runs into difficulty in finding the end of the argument. Since
|
|
manipulating diversions during argument collection is inherently
|
|
unsafe, <CODE>m4_expand</CODE> issues an error if
|
|
<VAR>arg</VAR> attempts to change the current
|
|
diversion (Diversion support).</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([active], [ACT, IVE])dnl
|
|
m4_define([active2], [[ACT, IVE]])dnl m4_quote(active, active)
|
|
ACT,IVE,ACT,IVE m4_expand([active, active]) ACT, IVE, ACT, IVE
|
|
m4_quote(active2, active2) ACT, IVE,ACT, IVE m4_expand([active2,
|
|
active2]) ACT, IVE, ACT, IVE m4_expand([# m4_echo]) # m4_echo
|
|
m4_quote(# m4_echo) ) # m4_echo)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Note that <CODE>m4_expand</CODE> cannot handle an
|
|
<VAR>arg</VAR> that expands to literal unbalanced
|
|
quotes, but that quadrigraphs can be used when unbalanced output
|
|
is necessary. Likewise, unbalanced parentheses should be
|
|
supplied with double quoting or a quadrigraph.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([pattern],
|
|
[[!@@<:@@]])dnl m4_define([bar], [BAR])dnl m4_expand([case
|
|
$foo in m4_defn([pattern])@@:@}@@ bar ;; *[)] blah ;; esac])
|
|
case $foo in [![]) BAR ;; *) blah ;; esac
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_ignore">
|
|
<prototype>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62. Expands to
|
|
nothing, ignoring all of its arguments. By itself, this isn't
|
|
very useful. However, it can be used to conditionally ignore an
|
|
arbitrary number of arguments, by deciding which macro name to
|
|
apply to a list of arguments.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> dnl foo outputs a message only if
|
|
[debug] is defined. m4_define([foo],
|
|
[m4_ifdef([debug],[AC_MSG_NOTICE],[m4_ignore])([debug
|
|
message])]) </pre></td></tr></table></P><P>
|
|
|
|
Note that for earlier versions of Autoconf, the macro
|
|
<CODE>__gnu__</CODE> can serve the same purpose,
|
|
although it is less readable.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_make_list">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro exists to aid debugging of M4sugar algorithms. Its
|
|
net effect is similar to <CODE>m4_dquote</CODE>---it
|
|
produces a quoted list of quoted arguments, for each
|
|
<VAR>arg</VAR>. The difference is that this version
|
|
uses a comma-newline separator instead of just comma, to improve
|
|
readability of the list; with the result that it is less
|
|
efficient than <CODE>m4_dquote</CODE>.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_define([zero],[0])m4_define([one],[1])m4_define([two],[2])dnl
|
|
m4_dquote(zero, [one], [[two]]) [0],[one],[[two]]
|
|
m4_make_list(zero, [one], [[two]]) [0], [one], [[two]]
|
|
m4_foreach([number], m4_dquote(zero, [one], [[two]]), [ number])
|
|
0 1 two m4_foreach([number], m4_make_list(zero, [one],
|
|
[[two]]), [ number]) 0 1 two
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_quote">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Return the arguments as a single entity, i.e., wrap them into a
|
|
pair of quotes. This effectively collapses multiple arguments
|
|
into one, although it loses whitespace after unquoted commas in
|
|
the process.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_reverse">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Outputs each argument with the same level of quoting, but in
|
|
reverse order, and with space following each comma for
|
|
readability.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([active], [ACT,IVE])
|
|
m4_reverse(active, [active]) active, IVE, ACT
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_unquote">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62. Expand each
|
|
argument, separated by commas. For a single
|
|
<VAR>arg</VAR>, this effectively removes a layer of
|
|
quoting, and
|
|
<CODE>m4_unquote([<VAR>arg</VAR>])</CODE>
|
|
is more efficient than the equivalent
|
|
<CODE>m4_do([<VAR>arg</VAR>])</CODE>.
|
|
For multiple arguments, this results in an unquoted list of
|
|
expansions. This is commonly used with
|
|
<CODE>m4_split</CODE>, in order to convert a single
|
|
quoted list into a series of quoted elements.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_append">
|
|
<prototype>
|
|
<parameter content="macro-name"/>
|
|
<parameter content="string"/>
|
|
<parameter content="[separator]"/>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
if-uniq, if-duplicate) Redefine
|
|
<VAR>macro-name</VAR> to its former contents with
|
|
<VAR>separator</VAR> and
|
|
<VAR>string</VAR> added at the end. If
|
|
<VAR>macro-name</VAR> was undefined before (but not
|
|
if it was defined but empty), then no
|
|
<VAR>separator</VAR> is added. As of Autoconf 2.62,
|
|
neither <VAR>string</VAR> nor
|
|
<VAR>separator</VAR> are expanded during this macro;
|
|
instead, they are expanded when
|
|
<VAR>macro-name</VAR> is invoked.</P><P>
|
|
|
|
<CODE>m4_append</CODE> can be used to grow strings,
|
|
and <CODE>m4_append_uniq</CODE> to grow strings
|
|
without duplicating substrings. Additionally,
|
|
<CODE>m4_append_uniq</CODE> takes two optional
|
|
parameters as of Autoconf 2.62; <VAR>if-uniq</VAR>
|
|
is expanded if <VAR>string</VAR> was appended, and
|
|
<VAR>if-duplicate</VAR> is expanded if
|
|
<VAR>string</VAR> was already present. Also,
|
|
<CODE>m4_append_uniq</CODE> warns if
|
|
<VAR>separator</VAR> is not empty, but occurs within
|
|
<VAR>string</VAR>, since that can lead to
|
|
duplicates.</P><P>
|
|
|
|
Note that <CODE>m4_append</CODE> can scale linearly
|
|
in the length of the final string, depending on the quality of
|
|
the underlying M4 implementation, while
|
|
<CODE>m4_append_uniq</CODE> has an inherent
|
|
quadratic scaling factor. If an algorithm can tolerate
|
|
duplicates in the final string, use the former for speed. If
|
|
duplicates must be avoided, consider using
|
|
<CODE>m4_set_add</CODE> instead (Set manipulation
|
|
Macros).</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([active], [ACTIVE])dnl
|
|
m4_append([sentence], [This is an])dnl m4_append([sentence], [
|
|
active ])dnl m4_append([sentence], [symbol.])dnl sentence This
|
|
is an ACTIVE symbol. m4_undefine([active])dnl This is an active
|
|
symbol. m4_append_uniq([list], [one], [, ], [new], [existing])
|
|
new m4_append_uniq([list], [one], [, ], [new], [existing])
|
|
existing m4_append_uniq([list], [two], [, ], [new], [existing])
|
|
new m4_append_uniq([list], [three], [, ], [new], [existing]) new
|
|
m4_append_uniq([list], [two], [, ], [new], [existing]) existing
|
|
list one, two, three m4_dquote(list) [one],[two],[three]
|
|
m4_append([list2], [one], [[, ]])dnl m4_append_uniq([list2],
|
|
[two], [[, ]])dnl m4_append([list2], [three], [[, ]])dnl list2
|
|
one, two, three m4_dquote(list2) [one, two, three]
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_append_uniq_w">
|
|
<prototype>
|
|
<parameter content="macro-name"/>
|
|
<parameter content="strings"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62. It is similar to
|
|
<CODE>m4_append_uniq</CODE>, but treats
|
|
<VAR>strings</VAR> as a whitespace separated list of
|
|
words to append, and only appends unique words.
|
|
<VAR>macro-name</VAR> is updated with a single space
|
|
between new words.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_append_uniq_w([numbers], [1 1
|
|
2])dnl m4_append_uniq_w([numbers], [ 2 3 ])dnl numbers 1 2 3
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_chomp">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Output <VAR>string</VAR> in quotes, but without a
|
|
trailing newline. The macro <CODE>m4_chomp</CODE>
|
|
is slightly faster, and removes at most one newline; the macro
|
|
<CODE>m4_chomp_all</CODE> removes all consecutive
|
|
trailing newlines. Unlike <CODE>m4_flatten</CODE>,
|
|
embedded newlines are left intact, and backslash does not
|
|
influence the result.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_combine">
|
|
<prototype>
|
|
<parameter content="[separator]"/>
|
|
<parameter content="prefix-list"/>
|
|
<parameter content="[infix]"/>
|
|
<parameter content="@ suffix-1"/>
|
|
<parameter content="[suffix-2]"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro produces a quoted string containing the pairwise
|
|
combination of every element of the quoted, comma-separated
|
|
<VAR>prefix-list</VAR>, and every element from the
|
|
<VAR>suffix</VAR> arguments. Each pairwise
|
|
combination is joined with <VAR>infix</VAR> in the
|
|
middle, and successive pairs are joined by
|
|
<VAR>separator</VAR>. No expansion occurs on any of
|
|
the arguments. No output occurs if either the
|
|
<VAR>prefix</VAR> or <VAR>suffix</VAR>
|
|
list is empty, but the lists can contain empty elements.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([a], [oops])dnl
|
|
m4_combine([, ], [[a], [b], [c]], [-], [1], [2], [3]) a-1, a-2,
|
|
a-3, b-1, b-2, b-3, c-1, c-2, c-3 m4_combine([, ], [[a], [b]],
|
|
[-]) m4_combine([, ], [[a], [b]], [-], []) a-, b- m4_combine([,
|
|
], [], [-], [1], [2]) m4_combine([, ], [[]], [-], [1], [2]) -1,
|
|
-2 </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_escape">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Convert all instances of <samp>[</samp>,
|
|
<samp>]</samp>, <samp>#</samp>, and
|
|
<samp>$</samp> within <VAR>string</VAR>
|
|
into their respective quadrigraphs. The result is still a
|
|
quoted string.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_flatten">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Flatten <VAR>string</VAR> into a single line.
|
|
Delete all backslash-newline pairs, and replace all remaining
|
|
newlines with a space. The result is still a quoted string.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_join">
|
|
<prototype>
|
|
<parameter content="[separator]"/>
|
|
<parameter content="args..."/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="[separator]"/>
|
|
<parameter content="args..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Concatenate each <VAR>arg</VAR>, separated by
|
|
<VAR>separator</VAR>.
|
|
<CODE>joinall</CODE> uses every argument, while
|
|
<CODE>join</CODE> omits empty arguments so that
|
|
there are no back-to-back separators in the output. The result
|
|
is a quoted string.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([active], [ACTIVE])dnl
|
|
m4_join([|], [one], [], [active], [two]) one|active|two
|
|
m4_joinall([|], [one], [], [active], [two]) one||active|two
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Note that if all you intend to do is join
|
|
<VAR>args</VAR> with commas between them, to form a
|
|
quoted list suitable for <CODE>m4_foreach</CODE>, it
|
|
is more efficient to use <CODE>m4_dquote</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_newline">
|
|
<prototype>
|
|
<parameter content="[text]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62, and expands to a
|
|
newline, followed by any <VAR>text</VAR>. It is
|
|
primarily useful for maintaining macro formatting, and ensuring
|
|
that M4 does not discard leading whitespace during argument
|
|
collection.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_normalize">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Remove leading and trailing spaces and tabs, sequences of
|
|
backslash-then-newline, and replace multiple spaces, tabs, and
|
|
newlines with a single space. This is a combination of
|
|
<CODE>m4_flatten</CODE> and
|
|
<CODE>m4_strip</CODE>. To determine if
|
|
<VAR>string</VAR> consists only of bytes that would
|
|
be removed by <CODE>m4_normalize</CODE>, you can use
|
|
<CODE>m4_ifblank</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_re_escape">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Backslash-escape all characters in
|
|
<VAR>string</VAR> that are active in regexps.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_split">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="[regexp = @samp{[\t ]+}]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Split <VAR>string</VAR> into an M4 list of elements
|
|
quoted by <samp>[</samp> and
|
|
<samp>]</samp>, while keeping white space at the
|
|
beginning and at the end. If <VAR>regexp</VAR> is
|
|
given, use it instead of <samp>[\t ]+</samp> for
|
|
splitting. If <VAR>string</VAR> is empty, the result
|
|
is an empty list.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_strip">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Strip whitespace from <VAR>string</VAR>. Sequences
|
|
of spaces and tabs are reduced to a single space, then leading
|
|
and trailing spaces are removed. The result is still a quoted
|
|
string. Note that this does not interfere with newlines; if you
|
|
want newlines stripped as well, consider
|
|
<CODE>m4_flatten</CODE>, or do it all at once with
|
|
<CODE>m4_normalize</CODE>. To quickly test if
|
|
<VAR>string</VAR> has only whitespace, use
|
|
<CODE>m4_ifblank</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_text_box">
|
|
<prototype>
|
|
<parameter content="message"/>
|
|
<parameter content="[frame= -]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Add a text box around <VAR>message</VAR>, using
|
|
<VAR>frame</VAR> as the border character above and
|
|
below the message. The <VAR>frame</VAR> argument
|
|
must be a single byte, and does not support quadrigraphs. The
|
|
frame correctly accounts for the subsequent expansion of
|
|
<VAR>message</VAR>. For example:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([macro], [abc])dnl
|
|
m4_text_box([macro]) ## --- ## ## abc ## ## --- ##
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The <VAR>message</VAR> must contain balanced quotes
|
|
and parentheses, although quadrigraphs can be used to work
|
|
around this.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_text_wrap">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="[prefix]"/>
|
|
<parameter content="@ [prefix1= prefix]"/>
|
|
<parameter content="[width= 79]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Break <VAR>string</VAR> into a series of
|
|
whitespace-separated words, then output those words separated by
|
|
spaces, and wrapping lines any time the output would exceed
|
|
<VAR>width</VAR> columns. If given,
|
|
<VAR>prefix1</VAR> begins the first line, and
|
|
<VAR>prefix</VAR> begins all wrapped lines. If
|
|
<VAR>prefix1</VAR> is longer than
|
|
<VAR>prefix</VAR>, then the first line consists of
|
|
just <VAR>prefix1</VAR>. If
|
|
<VAR>prefix</VAR> is longer than
|
|
<VAR>prefix1</VAR>, padding is inserted so that the
|
|
first word of <VAR>string</VAR> begins at the same
|
|
indentation as all wrapped lines. Note that using literal tab
|
|
characters in any of the arguments will interfere with the
|
|
calculation of width. No expansions occur on
|
|
<VAR>prefix</VAR>, <VAR>prefix1</VAR>,
|
|
or the words of <VAR>string</VAR>, although
|
|
quadrigraphs are recognized.</P><P>
|
|
|
|
For some examples:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_text_wrap([Short string */], [
|
|
], [/* ], [20]) /* Short string */ m4_text_wrap([Much longer
|
|
string */], [ ], [/* ], [20]) /* Much longer string */
|
|
m4_text_wrap([Short doc.], [ ], [ --short ], [30])
|
|
--short Short doc. m4_text_wrap([Short doc.], [ ], [
|
|
--too-wide ], [30]) --too-wide Short doc.
|
|
m4_text_wrap([Super long documentation.], [ ],
|
|
[ --too-wide ], 30) --too-wide Super long
|
|
documentation. </pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_tolower">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Return <VAR>string</VAR> with letters converted to
|
|
upper or lower case, respectively.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_cmp">
|
|
<prototype>
|
|
<parameter content="expr-1"/>
|
|
<parameter content="expr-2"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Compare the arithmetic expressions
|
|
<VAR>expr-1</VAR> and <VAR>expr-2</VAR>,
|
|
and expand to <samp>-1</samp> if
|
|
<VAR>expr-1</VAR> is smaller,
|
|
<samp>0</samp> if they are equal, and
|
|
<samp>1</samp> if <VAR>expr-1</VAR> is
|
|
larger.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_list_cmp">
|
|
<prototype>
|
|
<parameter content="list-1"/>
|
|
<parameter content="list-2"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Compare the two M4 lists consisting of comma-separated
|
|
arithmetic expressions, left to right. Expand to
|
|
<samp>-1</samp> for the first element pairing where
|
|
the value from <VAR>list-1</VAR> is smaller,
|
|
<samp>1</samp> where the value from
|
|
<VAR>list-2</VAR> is smaller, or
|
|
<samp>0</samp> if both lists have the same values.
|
|
If one list is shorter than the other, the remaining elements of
|
|
the longer list are compared against zero.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_list_cmp([1, 0], [1]) 0
|
|
m4_list_cmp([1, [1 * 0]], [1, 0]) 0 m4_list_cmp([1, 2],
|
|
[1, 0]) 1 m4_list_cmp([1, [1+1], 3],[1, 2]) 1 m4_list_cmp([1, 2,
|
|
-3], [1, 2]) -1 m4_list_cmp([1, 0], [1, 2]) -1
|
|
m4_list_cmp([1], [1, 2]) -1
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_max">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62. Expand to the
|
|
decimal value of the maximum arithmetic expression among all the
|
|
arguments.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_min">
|
|
<prototype>
|
|
<parameter content="arg"/>
|
|
<parameter content="..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.62. Expand to the
|
|
decimal value of the minimum arithmetic expression among all the
|
|
arguments.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_sign">
|
|
<prototype>
|
|
<parameter content="expr"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand to <samp>-1</samp> if the arithmetic
|
|
expression <VAR>expr</VAR> is negative,
|
|
<samp>1</samp> if it is positive, and
|
|
<samp>0</samp> if it is zero.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_version_compare">
|
|
<prototype>
|
|
<parameter content="version-1"/>
|
|
<parameter content="version-2"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was introduced in Autoconf 2.53, but had a number of
|
|
usability limitations that were not lifted until Autoconf 2.62.
|
|
Compare the version strings <VAR>version-1</VAR> and
|
|
<VAR>version-2</VAR>, and expand to
|
|
<samp>-1</samp> if <VAR>version-1</VAR>
|
|
is smaller, <samp>0</samp> if they are the same, or
|
|
<samp>1</samp> <VAR>version-2</VAR> is
|
|
smaller. Version strings must be a list of elements separated
|
|
by <samp>.</samp>, <samp>,</samp> or
|
|
<samp>-</samp>, where each element is a number along
|
|
with optional case-insensitive letters designating beta
|
|
releases. The comparison stops at the leftmost element that
|
|
contains a difference, although a 0 element compares equal to a
|
|
missing element.</P><P>
|
|
|
|
It is permissible to include commit identifiers in
|
|
<VAR>version</VAR>, such as an abbreviated SHA1 of
|
|
the commit, provided there is still a monotonically increasing
|
|
prefix to allow for accurate version-based comparisons. For
|
|
example, this paragraph was written when the development
|
|
snapshot of autoconf claimed to be at version
|
|
<samp>2.61a-248-dc51</samp>, or 248 commits after
|
|
the 2.61a release, with an abbreviated commit identification of
|
|
<samp>dc51</samp>.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_version_compare([1.1], [2.0]) -1
|
|
m4_version_compare([2.0b], [2.0a]) 1 m4_version_compare([1.1.1],
|
|
[1.1.1a]) -1 m4_version_compare([1.2], [1.1.1a]) 1
|
|
m4_version_compare([1.0], [1]) 0 m4_version_compare([1.1pre],
|
|
[1.1PRE]) 0 m4_version_compare([1.1a], [1,10]) -1
|
|
m4_version_compare([2.61a], [2.61a-248-dc51]) -1
|
|
m4_version_compare([2.61b], [2.61a-248-dc51]) 1
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_version_prereq">
|
|
<prototype>
|
|
<parameter content="version"/>
|
|
<parameter content="[if-new-enough]"/>
|
|
<parameter content="@ [if-old= m4_fatal]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Compares <VAR>version</VAR> against the version of
|
|
Autoconf currently running. If the running version is at
|
|
<VAR>version</VAR> or newer, expand
|
|
<VAR>if-new-enough</VAR>, but if
|
|
<VAR>version</VAR> is larger than the version
|
|
currently executing, expand <VAR>if-old</VAR>, which
|
|
defaults to printing an error message and exiting m4sugar with
|
|
status 63. When given only one argument, this behaves like
|
|
<CODE>AC_PREREQ</CODE> (Versioning). Remember that
|
|
the autoconf philosophy favors feature checks over version
|
|
checks.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_add">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="value"/>
|
|
<parameter content="[if-uniq]"/>
|
|
<parameter content="[if-dup]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Adds the string <VAR>value</VAR> as a member of set
|
|
<VAR>set</VAR>. Expand
|
|
<VAR>if-uniq</VAR> if the element was added, or
|
|
<VAR>if-dup</VAR> if it was previously in the set.
|
|
Operates in amortized constant time, so that set creation scales
|
|
linearly.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_add_all">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="value..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
Adds each <VAR>value</VAR> to the set
|
|
<VAR>set</VAR>. This is slightly more efficient
|
|
than repeatedly invoking <CODE>m4_set_add</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_contains">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="value"/>
|
|
<parameter content="[if-present]"/>
|
|
<parameter content="@ [if-absent]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands <VAR>if-present</VAR> if the string
|
|
<VAR>value</VAR> is a member of
|
|
<VAR>set</VAR>, otherwise
|
|
<VAR>if-absent</VAR>.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_set_contains([a], [1], [yes],
|
|
[no]) no m4_set_add([a], [1], [added], [dup]) added
|
|
m4_set_add([a], [1], [added], [dup]) dup m4_set_contains([a],
|
|
[1], [yes], [no]) yes m4_set_remove([a], [1], [removed],
|
|
[missing]) removed m4_set_contains([a], [1], [yes], [no]) no
|
|
m4_set_remove([a], [1], [removed], [missing]) missing
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_contents">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="[sep]"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="[sep]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands to a single string consisting of all the members of
|
|
the set <VAR>set</VAR>, each separated by
|
|
<VAR>sep</VAR>, which is not expanded.
|
|
<CODE>m4_set_contents</CODE> leaves the elements in
|
|
<VAR>set</VAR> but reclaims any memory occupied by
|
|
removed elements, while <CODE>m4_set_dump</CODE> is
|
|
a faster one-shot action that also deletes the set. No
|
|
provision is made for disambiguating members that contain a
|
|
non-empty <VAR>sep</VAR> as a substring; use
|
|
<CODE>m4_set_empty</CODE> to distinguish between an
|
|
empty set and the set containing only the empty string. The
|
|
order of the output is unspecified; in the current
|
|
implementation, part of the speed of
|
|
<CODE>m4_set_dump</CODE> results from using a
|
|
different output order than
|
|
<CODE>m4_set_contents</CODE>. These macros scale
|
|
linearly in the size of the set before memory pruning, and
|
|
<CODE>m4_set_contents([<VAR>set</VAR>],
|
|
[<VAR>sep</VAR>])</CODE> is faster than
|
|
<CODE>m4_joinall([<VAR>sep</VAR>]m4_set_listc([<VAR>set</VAR>]))</CODE>.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_set_add_all([a], [1], [2], [3])
|
|
m4_set_contents([a], [-]) 1-2-3 m4_joinall([-]m4_set_listc([a]))
|
|
1-2-3 m4_set_dump([a], [-]) 3-2-1 m4_set_contents([a])
|
|
m4_set_add([a], []) m4_set_contents([a], [-])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_delete">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Delete all elements and memory associated with
|
|
<VAR>set</VAR>. This is linear in the set size, and
|
|
faster than removing one element at a time.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_difference">
|
|
<prototype>
|
|
<parameter content="seta"/>
|
|
<parameter content="setb"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="seta"/>
|
|
<parameter content="setb"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="seta"/>
|
|
<parameter content="setb"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Compute the relation between <VAR>seta</VAR> and
|
|
<VAR>setb</VAR>, and output the result as a list of
|
|
quoted arguments without duplicates and with a leading comma.
|
|
Set difference selects the elements in
|
|
<VAR>seta</VAR> but not <VAR>setb</VAR>,
|
|
intersection selects only elements in both sets, and union
|
|
selects elements in either set. These actions are linear in the
|
|
sum of the set sizes. The leading comma is necessary to
|
|
distinguish between no elements and the empty string as the only
|
|
element.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_set_add_all([a], [1], [2], [3])
|
|
m4_set_add_all([b], [3], [], [4]) m4_set_difference([a], [b])
|
|
,1,2 m4_set_difference([b], [a]) ,,4 m4_set_intersection([a],
|
|
[b]) ,3 m4_set_union([a], [b]) ,1,2,3,,4
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_empty">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="[if-empty]"/>
|
|
<parameter content="[if-elements]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand <VAR>if-empty</VAR> if the set
|
|
<VAR>set</VAR> has no elements, otherwise expand
|
|
<VAR>if-elements</VAR>. This macro operates in
|
|
constant time. Using this macro can help disambiguate output
|
|
from <CODE>m4_set_contents</CODE> or
|
|
<CODE>m4_set_list</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_foreach">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="variable"/>
|
|
<parameter content="action"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each element in the set <VAR>set</VAR>, expand
|
|
<VAR>action</VAR> with the macro
|
|
<VAR>variable</VAR> defined as the set element.
|
|
Behavior is unspecified if <VAR>action</VAR>
|
|
recursively lists the contents of <VAR>set</VAR>
|
|
(although listing other sets is acceptable), or if it modifies
|
|
the set in any way other than removing the element currently
|
|
contained in <VAR>variable</VAR>. This macro is
|
|
faster than the corresponding
|
|
<CODE>m4_foreach([<VAR>variable</VAR>],
|
|
m4_indir([m4_dquote]m4_set_listc([<VAR>set</VAR>])),
|
|
[<VAR>action</VAR>])</CODE>, although
|
|
<CODE>m4_set_map</CODE> might be faster still.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_set_add_all([a]m4_for([i], [1],
|
|
[5], [], [,i])) m4_set_contents([a]) 12345 m4_set_foreach([a],
|
|
[i], [m4_if(m4_eval(i&1), [0], [m4_set_remove([a], i,
|
|
[i])])]) 24 m4_set_contents([a]) 135
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_list">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Produce a list of arguments, where each argument is a quoted
|
|
element from the set <VAR>set</VAR>. The variant
|
|
<CODE>m4_set_listc</CODE> is unambiguous, by adding
|
|
a leading comma if there are any set elements, whereas the
|
|
variant <CODE>m4_set_list</CODE> cannot distinguish
|
|
between an empty set and a set containing only the empty string.
|
|
These can be directly used in macros that take multiple
|
|
arguments, such as <CODE>m4_join</CODE> or
|
|
<CODE>m4_set_add_all</CODE>, or wrapped by
|
|
<CODE>m4_dquote</CODE> for macros that take a quoted
|
|
list, such as <CODE>m4_map</CODE> or
|
|
<CODE>m4_foreach</CODE>. Any memory occupied by
|
|
removed elements is reclaimed during these macros.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_set_add_all([a], [1], [2], [3])
|
|
m4_set_list([a]) 1,2,3 m4_set_list([b]) m4_set_listc([b])
|
|
m4_count(m4_set_list([b])) 1 m4_set_empty([b], [0],
|
|
[m4_count(m4_set_list([b]))]) 0 m4_set_add([b], [])
|
|
m4_set_list([b]) m4_set_listc([b]) , m4_count(m4_set_list([b]))
|
|
1 m4_set_empty([b], [0], [m4_count(m4_set_list([b]))]) 1
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_map">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="action"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each element in the set <VAR>set</VAR>, expand
|
|
<VAR>action</VAR> with a single argument of the set
|
|
element. Behavior is unspecified if
|
|
<VAR>action</VAR> recursively lists the contents of
|
|
<VAR>set</VAR> (although listing other sets is
|
|
acceptable), or if it modifies the set in any way other than
|
|
removing the element passed as an argument. This macro is
|
|
faster than either corresponding counterpart of
|
|
<CODE>m4_map_args([<VAR>action</VAR>]m4_set_listc([<VAR>set</VAR>]))</CODE>
|
|
or <CODE>m4_set_foreach([<VAR>set</VAR>],
|
|
[var],
|
|
[<VAR>action</VAR>(m4_defn([var]))])</CODE>.
|
|
It is possible to use <CODE>m4_curry</CODE> if more
|
|
than one argument is needed for <VAR>action</VAR>,
|
|
although it is more efficient to use
|
|
<CODE>m4_set_map_sep</CODE> in that case.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_map_sep">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="[pre]"/>
|
|
<parameter content="[post]"/>
|
|
<parameter content="[sep]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
For each element in the set <VAR>set</VAR>, expand
|
|
<CODE><VAR>pre</VAR>[element]<VAR>post</VAR></CODE>,
|
|
additionally expanding <VAR>sep</VAR> between
|
|
elements. Behavior is unspecified if the expansion recursively
|
|
lists the contents of <VAR>set</VAR> (although
|
|
listing other sets is acceptable), or if it modifies the set in
|
|
any way other than removing the element visited by the
|
|
expansion. This macro provides the most efficient means for
|
|
non-destructively visiting the elements of a set; in particular,
|
|
<CODE>m4_set_map([<VAR>set</VAR>],
|
|
[<VAR>action</VAR>])</CODE> is equivalent to
|
|
<CODE>m4_set_map_sep([<VAR>set</VAR>],
|
|
[<VAR>action</VAR>(], [)])</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_remove">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
<parameter content="value"/>
|
|
<parameter content="[if-present]"/>
|
|
<parameter content="@ [if-absent]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If <VAR>value</VAR> is an element in the set
|
|
<VAR>set</VAR>, then remove it and expand
|
|
<VAR>if-present</VAR>. Otherwise expand
|
|
<VAR>if-absent</VAR>. This macro operates in
|
|
constant time so that multiple removals will scale linearly
|
|
rather than quadratically; but when used outside of
|
|
<CODE>m4_set_foreach</CODE> or
|
|
<CODE>m4_set_map</CODE>, it leaves memory occupied
|
|
until the set is later compacted by
|
|
<CODE>m4_set_contents</CODE> or
|
|
<CODE>m4_set_list</CODE>. Several other set
|
|
operations are then less efficient between the time of element
|
|
removal and subsequent memory compaction, but still maintain
|
|
their guaranteed scaling performance.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_set_size">
|
|
<prototype>
|
|
<parameter content="set"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand to the size of the set <VAR>set</VAR>. This
|
|
implementation operates in constant time, and is thus more
|
|
efficient than <CODE>m4_eval(m4_count(m4_set_listc([set]))
|
|
- 1)</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_pattern_forbid">
|
|
<prototype>
|
|
<parameter content="pattern"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Declare that no token matching <VAR>pattern</VAR>
|
|
must be found in the output. Comments are not checked; this can
|
|
be a problem if, for instance, you have some macro left
|
|
unexpanded after an <samp>#include</samp>. No
|
|
consensus is currently found in the Autoconf community, as some
|
|
people consider it should be valid to name macros in comments
|
|
(which doesn't make sense to the authors of this documentation:
|
|
input, such as macros, should be documented by
|
|
<samp>dnl</samp> comments; reserving
|
|
<samp>#</samp>-comments to document the output).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="m4_pattern_allow">
|
|
<prototype>
|
|
<parameter content="pattern"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Any token matching <VAR>pattern</VAR> is allowed,
|
|
including if it matches an
|
|
<CODE>m4_pattern_forbid</CODE> pattern.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_BASENAME">
|
|
<prototype>
|
|
<parameter content="file-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Output the non-directory portion of
|
|
<VAR>file-name</VAR>. For example, if
|
|
<CODE>$file</CODE> is
|
|
<samp>/one/two/three</samp>, the command
|
|
<CODE>base=`AS_BASENAME(["$file"])`</CODE> sets
|
|
<CODE>base</CODE> to <samp>three</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_BOX">
|
|
<prototype>
|
|
<parameter content="text"/>
|
|
<parameter content="[char= -]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand into shell code that will output
|
|
<VAR>text</VAR> surrounded by a box with
|
|
<VAR>char</VAR> in the top and bottom border.
|
|
<VAR>text</VAR> should not contain a newline, but
|
|
may contain shell expansions valid for unquoted here-documents.
|
|
<VAR>char</VAR> defaults to
|
|
<samp>-</samp>, but can be any character except
|
|
<samp>/</samp>, <samp>'</samp>,
|
|
<samp>"</samp>, <samp>\</samp>,
|
|
<samp>&</samp>, or <samp>`</samp>.
|
|
This is useful for outputting a comment box into log files to
|
|
separate distinct phases of script operation.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_CASE">
|
|
<prototype>
|
|
<parameter content="word"/>
|
|
<parameter content="[pattern1]"/>
|
|
<parameter content="[if-matched1]"/>
|
|
<parameter content="@ ..."/>
|
|
<parameter content="[default]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expand into a shell <samp>case</samp> statement,
|
|
where <VAR>word</VAR> is matched against one or more
|
|
patterns. <VAR>if-matched</VAR> is run if the
|
|
corresponding pattern matched <VAR>word</VAR>, else
|
|
<VAR>default</VAR> is run. Avoids several
|
|
portability issues (case, , Limitations of Shell Builtins).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_DIRNAME">
|
|
<prototype>
|
|
<parameter content="file-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Output the directory portion of
|
|
<VAR>file-name</VAR>. For example, if
|
|
<CODE>$file</CODE> is
|
|
<samp>/one/two/three</samp>, the command
|
|
<CODE>dir=`AS_DIRNAME(["$file"])`</CODE> sets
|
|
<CODE>dir</CODE> to
|
|
<samp>/one/two</samp>.</P><P>
|
|
|
|
This interface may be improved in the future to avoid forks and
|
|
losing trailing newlines.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_ECHO">
|
|
<prototype>
|
|
<parameter content="word"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emits <VAR>word</VAR> to the standard output,
|
|
followed by a newline. <VAR>word</VAR> must be a
|
|
single shell word (typically a quoted string). The bytes of
|
|
<VAR>word</VAR> are output as-is, even if it starts
|
|
with "-" or contains "\". Redirections can be placed outside the
|
|
macro invocation. This is much more portable than using
|
|
<CODE>echo</CODE> (echo, , Limitations of Shell
|
|
Builtins).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_ECHO_N">
|
|
<prototype>
|
|
<parameter content="word"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emits <VAR>word</VAR> to the standard output,
|
|
without a following newline. <VAR>word</VAR> must be
|
|
a single shell word (typically a quoted string) and, for
|
|
portability, should not include more than one newline. The
|
|
bytes of <VAR>word</VAR> are output as-is, even if
|
|
it starts with "-" or contains "\". Redirections can be placed
|
|
outside the macro invocation.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_ESCAPE">
|
|
<prototype>
|
|
<parameter content="string"/>
|
|
<parameter content="[chars = @samp{`\"$}]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Expands to <VAR>string</VAR>, with any characters
|
|
in <VAR>chars</VAR> escaped with a backslash
|
|
(<samp>\</samp>). <VAR>chars</VAR>
|
|
should be at most four bytes long, and only contain characters
|
|
from the set <samp>`\"$</samp>; however, characters
|
|
may be safely listed more than once in
|
|
<VAR>chars</VAR> for the sake of syntax highlighting
|
|
editors. The current implementation expands
|
|
<VAR>string</VAR> after adding escapes; if
|
|
<VAR>string</VAR> contains macro calls that in turn
|
|
expand to text needing shell quoting, you can use
|
|
<CODE>AS_ESCAPE(m4_dquote(m4_expand([string])))</CODE>.</P><P>
|
|
|
|
The default for <VAR>chars</VAR>
|
|
(<samp>\"$`</samp>) is the set of characters needing
|
|
escapes when <VAR>string</VAR> will be used
|
|
literally within double quotes. One common variant is the set
|
|
of characters to protect when <VAR>string</VAR> will
|
|
be used literally within back-ticks or an unquoted here-document
|
|
(<samp>\$`</samp>). Another common variant is
|
|
<samp>""</samp>, which can be used to form a
|
|
double-quoted string containing the same expansions that would
|
|
have occurred if <VAR>string</VAR> were expanded in
|
|
an unquoted here-document; however, when using this variant,
|
|
care must be taken that <VAR>string</VAR> does not
|
|
use double quotes within complex variable expansions (such as
|
|
<samp>$foo-`echo "hi"`@</samp>) that would be broken
|
|
with improper escapes.</P><P>
|
|
|
|
This macro is often used with <CODE>AS_ECHO</CODE>.
|
|
For an example, observe the output generated by the shell code
|
|
generated from this snippet:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> foo=bar AS_ECHO(["AS_ESCAPE(["$foo"
|
|
= ])AS_ESCAPE(["$foo"], [""])"]) "$foo" = "bar"
|
|
m4_define([macro], [a, [\b]]) AS_ECHO(["AS_ESCAPE([[macro]])"])
|
|
macro AS_ECHO(["AS_ESCAPE([macro])"]) a, b
|
|
AS_ECHO(["AS_ESCAPE(m4_dquote(m4_expand([macro])))"]) a, \b
|
|
</pre></td></tr></table></P><P>
|
|
|
|
To escape a string that will be placed within single quotes,
|
|
use:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_bpatsubst([[<VAR>string</VAR>]], ['], ['\\''])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_EXIT">
|
|
<prototype>
|
|
<parameter content="[status= $?]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit code to exit the shell with <VAR>status</VAR>,
|
|
defaulting to <samp>$?</samp>. This macro works
|
|
around shells that see the exit status of the command prior to
|
|
<CODE>exit</CODE> inside a <samp>trap
|
|
0</samp> handler (trap, , Limitations of Shell Builtins).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_IF">
|
|
<prototype>
|
|
<parameter content="test1"/>
|
|
<parameter content="[run-if-true1]"/>
|
|
<parameter content="..."/>
|
|
<parameter content="[run-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Run shell code <VAR>test1</VAR>. If
|
|
<VAR>test1</VAR> exits with a zero status then run
|
|
shell code <VAR>run-if-true1</VAR>, else examine
|
|
further tests. If no test exits with a zero status, run shell
|
|
code <VAR>run-if-false</VAR>, with simplifications
|
|
if either <VAR>run-if-true1</VAR> or
|
|
<VAR>run-if-false</VAR> is empty. For example,</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AS_IF([test "x$foo" = xyes],
|
|
[HANDLE_FOO([yes])], [test "x$foo" != xno],
|
|
[HANDLE_FOO([maybe])], [echo foo not specified])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
ensures any required macros of
|
|
<CODE>HANDLE_FOO</CODE> are expanded before the
|
|
first test.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_MKDIR_P">
|
|
<prototype>
|
|
<parameter content="file-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Make the directory <VAR>file-name</VAR>, including
|
|
intervening directories as necessary. This is equivalent to
|
|
<samp>mkdir -p --
|
|
<VAR>file-name</VAR></samp>, except that it is
|
|
portable to older versions of <CODE>mkdir</CODE>
|
|
that lack support for the <samp>-p</samp> option or
|
|
for the <samp>--</samp> delimiter (mkdir, ,
|
|
Limitations of Usual Tools). Also,
|
|
<CODE>AS_MKDIR_P</CODE> succeeds if
|
|
<VAR>file-name</VAR> is a symbolic link to an
|
|
existing directory, even though Posix is unclear whether
|
|
<samp>mkdir -p</samp> should succeed in that case.
|
|
If creation of <VAR>file-name</VAR> fails, exit the
|
|
script.</P><P>
|
|
|
|
Also see the <CODE>AC_PROG_MKDIR_P</CODE> macro
|
|
(Particular Programs).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_SET_STATUS">
|
|
<prototype>
|
|
<parameter content="status"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit shell code to set the value of <samp>$?</samp>
|
|
to <VAR>status</VAR>, as efficiently as possible.
|
|
However, this is not guaranteed to abort a shell running with
|
|
<CODE>set -e</CODE> (set, , Limitations of Shell
|
|
Builtins). This should also be used at the end of a complex
|
|
shell function instead of <samp>return</samp> (Shell
|
|
Functions) to avoid a DJGPP shell bug.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_TR_CPP">
|
|
<prototype>
|
|
<parameter content="expression"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Transform <VAR>expression</VAR> into a valid
|
|
right-hand side for a C <CODE>#define</CODE>. For
|
|
example:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> # This outputs "#define HAVE_CHAR_P
|
|
1". # Notice the m4 quoting around #, to prevent an m4 comment
|
|
type="char *" echo "[#]define AS_TR_CPP([HAVE_$type]) 1"
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_TR_SH">
|
|
<prototype>
|
|
<parameter content="expression"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Transform <VAR>expression</VAR> into shell code
|
|
that generates a valid shell variable name. The result is
|
|
literal when possible at m4 time, but must be used with
|
|
<CODE>eval</CODE> if
|
|
<VAR>expression</VAR> causes shell indirections. For
|
|
example:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> # This outputs "Have it!".
|
|
header="sys/some file.h" eval AS_TR_SH([HAVE_$header])=yes if
|
|
test "x$HAVE_sys_some_file_h" = xyes; then echo "Have it!"; fi
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_SET_CATFILE">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="dir"/>
|
|
<parameter content="file"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Set the polymorphic shell variable <VAR>var</VAR>
|
|
to <VAR>dir</VAR>/<VAR>file</VAR>, but
|
|
optimizing the common cases (<VAR>dir</VAR> or
|
|
<VAR>file</VAR> is <samp>.</samp>,
|
|
<VAR>file</VAR> is absolute, etc.).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_UNSET">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Unsets the shell variable <VAR>var</VAR>, working
|
|
around bugs in older shells (unset, , Limitations of Shell
|
|
Builtins). <VAR>var</VAR> can be a literal or
|
|
indirect variable name.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VERSION_COMPARE">
|
|
<prototype>
|
|
<parameter content="version-1"/>
|
|
<parameter content="version-2"/>
|
|
<parameter content="@ [action-if-less]"/>
|
|
<parameter content="[action-if-equal]"/>
|
|
<parameter content="[action-if-greater]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Compare two strings <VAR>version-1</VAR> and
|
|
<VAR>version-2</VAR>, possibly containing shell
|
|
variables, as version strings, and expand
|
|
<VAR>action-if-less</VAR>,
|
|
<VAR>action-if-equal</VAR>, or
|
|
<VAR>action-if-greater</VAR> depending upon the
|
|
result. The algorithm to compare is similar to the one used by
|
|
strverscmp in glibc (String/Array Comparison, , String/Array
|
|
Comparison, libc, The GNU C Library).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_LITERAL_IF">
|
|
<prototype>
|
|
<parameter content="expression"/>
|
|
<parameter content="[if-literal]"/>
|
|
<parameter content="[if-not]"/>
|
|
<parameter content="@ [if-simple-ref= if-not]"/>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
if-not, if-simple-ref, <VAR>if-not</VAR>) If the
|
|
expansion of <VAR>expression</VAR> is definitely a
|
|
shell literal, expand <VAR>if-literal</VAR>. If the
|
|
expansion of <VAR>expression</VAR> looks like it
|
|
might contain shell indirections (such as
|
|
<CODE>$var</CODE> or
|
|
<CODE>`expr`</CODE>), then
|
|
<VAR>if-not</VAR> is expanded. Sometimes, it is
|
|
possible to output optimized code if
|
|
<VAR>expression</VAR> consists only of shell
|
|
variable expansions (such as <CODE>$var@</CODE>), in
|
|
which case <VAR>if-simple-ref</VAR> can be provided;
|
|
but defaulting to <VAR>if-not</VAR> should always be
|
|
safe. <CODE>AS_LITERAL_WORD_IF</CODE> only expands
|
|
<VAR>if-literal</VAR> if
|
|
<VAR>expression</VAR> looks like a single shell
|
|
word, containing no whitespace; while
|
|
<CODE>AS_LITERAL_IF</CODE> allows whitespace in
|
|
<VAR>expression</VAR>.</P><P>
|
|
|
|
In order to reduce the time spent recognizing whether an
|
|
<VAR>expression</VAR> qualifies as a literal or a
|
|
simple indirection, the implementation is somewhat conservative:
|
|
<VAR>expression</VAR> must be a single shell word
|
|
(possibly after stripping whitespace), consisting only of bytes
|
|
that would have the same meaning whether unquoted or enclosed in
|
|
double quotes (for example, <samp>a.b</samp> results
|
|
in <VAR>if-literal</VAR>, even though it is not a
|
|
valid shell variable name; while both
|
|
<samp>'a'</samp> and <samp>[$]</samp>
|
|
result in <VAR>if-not</VAR>, because they behave
|
|
differently than <samp>"'a'"</samp> and
|
|
<samp>"[$]"</samp>). This macro can be used in
|
|
contexts for recognizing portable file names (such as in the
|
|
implementation of <CODE>AC_LIBSOURCE</CODE>), or
|
|
coupled with some transliterations for forming valid variable
|
|
names (such as in the implementation of
|
|
<CODE>AS_TR_SH</CODE>, which uses an additional
|
|
<CODE>m4_translit</CODE> to convert
|
|
<samp>.</samp> to <samp>_</samp>).</P><P>
|
|
|
|
This example shows how to read the contents of the shell
|
|
variable <CODE>bar</CODE>, exercising all three
|
|
arguments to <CODE>AS_LITERAL_IF</CODE>. It results
|
|
in a script that will output the line
|
|
<samp>hello</samp> three times.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_DEFUN([MY_ACTION],
|
|
[AS_LITERAL_IF([$1], [echo "$$1"], [AS_VAR_COPY([var], [$1])
|
|
echo "$var"], [eval 'echo "$'"$1"\"])]) foo=bar bar=hello
|
|
MY_ACTION([bar]) MY_ACTION([`echo bar`]) MY_ACTION([$foo])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_APPEND">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="text"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit shell code to append the shell expansion of
|
|
<VAR>text</VAR> to the end of the current contents
|
|
of the polymorphic shell variable <VAR>var</VAR>,
|
|
taking advantage of shells that provide the
|
|
<samp>+=</samp> extension for more efficient
|
|
scaling.</P><P>
|
|
|
|
For situations where the final contents of
|
|
<VAR>var</VAR> are relatively short (less than 256
|
|
bytes), it is more efficient to use the simpler code sequence of
|
|
<CODE><VAR>var</VAR>=$<VAR>var</VAR>@</CODE><VAR>text</VAR>
|
|
(or its polymorphic equivalent of <CODE>AS_VAR_COPY([t],
|
|
[<VAR>var</VAR>])</CODE> and
|
|
<CODE>AS_VAR_SET([<VAR>var</VAR>],
|
|
["$t"<VAR>text</VAR>])</CODE>). But in the
|
|
case when the script will be repeatedly appending text into
|
|
<CODE>var</CODE>, issues of scaling start to become
|
|
apparent. A naive implementation requires execution time linear
|
|
to the length of the current contents of
|
|
<VAR>var</VAR> as well as the length of
|
|
<VAR>text</VAR> for a single append, for an overall
|
|
quadratic scaling with multiple appends. This macro takes
|
|
advantage of shells which provide the extension
|
|
<CODE><VAR>var</VAR>+=<VAR>text</VAR></CODE>,
|
|
which can provide amortized constant time for a single append,
|
|
for an overall linear scaling with multiple appends. Note that
|
|
unlike <CODE>AS_VAR_SET</CODE>, this macro requires
|
|
that <VAR>text</VAR> be quoted properly to avoid
|
|
field splitting and file name expansion.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_ARITH">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="expression"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit shell code to compute the arithmetic expansion of
|
|
<VAR>expression</VAR>, assigning the result as the
|
|
contents of the polymorphic shell variable
|
|
<VAR>var</VAR>. The code takes advantage of shells
|
|
that provide <samp>$(())</samp> for fewer forks, but
|
|
uses <CODE>expr</CODE> as a fallback. Therefore,
|
|
the syntax for a valid <VAR>expression</VAR> is
|
|
rather limited: all operators must occur as separate shell
|
|
arguments and with proper quoting, there is no portable equality
|
|
operator, all variables containing numeric values must be
|
|
expanded prior to the computation, all numeric values must be
|
|
provided in decimal without leading zeroes, and the first shell
|
|
argument should not be a negative number. In the following
|
|
example, this snippet will print <samp>(2+3)*4 ==
|
|
20</samp>.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> bar=3 AS_VAR_ARITH([foo], [\( 2 +
|
|
$bar \) \* 4]) echo "(2+$bar)*4 == $foo"
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_COPY">
|
|
<prototype>
|
|
<parameter content="dest"/>
|
|
<parameter content="source"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit shell code to assign the contents of the polymorphic shell
|
|
variable <VAR>source</VAR> to the polymorphic shell
|
|
variable <VAR>dest</VAR>. For example, executing
|
|
this M4sh snippet will output <samp>bar hi</samp>:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> foo=bar bar=hi AS_VAR_COPY([a],
|
|
[foo]) AS_VAR_COPY([b], [$foo]) echo "$a $b"
|
|
</pre></td></tr></table></P><P>
|
|
|
|
When it is necessary to access the contents of an indirect
|
|
variable inside a shell double-quoted context, the recommended
|
|
idiom is to first copy the contents into a temporary literal
|
|
shell variable.</P><P>
|
|
|
|
@smallexample for header in stdint_h inttypes_h ; do
|
|
AS_VAR_COPY([var], [ac_cv_header_$header]) echo "$header
|
|
detected: $var" done @end smallexample
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_IF">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="[word]"/>
|
|
<parameter content="[if-equal]"/>
|
|
<parameter content="@ [if-not-equal]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Output a shell conditional statement. If the contents of the
|
|
polymorphic shell variable <VAR>var</VAR> match the
|
|
string <VAR>word</VAR>, execute
|
|
<VAR>if-equal</VAR>; otherwise execute
|
|
<VAR>if-not-equal</VAR>.
|
|
<VAR>word</VAR> must be a single shell word
|
|
(typically a quoted string). Avoids shell bugs if an interrupt
|
|
signal arrives while a command substitution in
|
|
<VAR>var</VAR> is being expanded.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_PUSHDEF">
|
|
<prototype>
|
|
<parameter content="m4-name"/>
|
|
<parameter content="value"/>
|
|
</prototype>
|
|
<prototype>
|
|
<parameter content="m4-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
variable names names, composing A common M4sh idiom involves
|
|
composing shell variable names from an m4 argument (for example,
|
|
writing a macro that uses a cache variable).
|
|
<VAR>value</VAR> can be an arbitrary string, which
|
|
will be transliterated into a valid shell name by
|
|
<CODE>AS_TR_SH</CODE>. In order to access the
|
|
composed variable name based on <VAR>value</VAR>, it
|
|
is easier to declare a temporary m4 macro
|
|
<VAR>m4-name</VAR> with
|
|
<CODE>AS_VAR_PUSHDEF</CODE>, then use that macro as
|
|
the argument to subsequent <CODE>AS_VAR</CODE>
|
|
macros as a polymorphic variable name, and finally free the
|
|
temporary macro with <CODE>AS_VAR_POPDEF</CODE>.
|
|
These macros are often followed with
|
|
<CODE>dnl</CODE>, to avoid excess newlines in the
|
|
output.</P><P>
|
|
|
|
Here is an involved example, that shows the power of writing
|
|
macros that can handle composed shell variable names:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_define([MY_CHECK_HEADER],
|
|
[AS_VAR_PUSHDEF([my_Header], [ac_cv_header_$1])dnl
|
|
AS_VAR_IF([my_Header], [yes], [echo "header $1 detected"])dnl
|
|
AS_VAR_POPDEF([my_Header])dnl ]) MY_CHECK_HEADER([stdint.h]) for
|
|
header in inttypes.h stdlib.h ; do MY_CHECK_HEADER([$header])
|
|
done </pre></td></tr></table></P><P>
|
|
|
|
In the above example, <CODE>MY_CHECK_HEADER</CODE>
|
|
can operate on polymorphic variable names. In the first
|
|
invocation, the m4 argument is
|
|
<CODE>stdint.h</CODE>, which transliterates into a
|
|
literal <CODE>stdint_h</CODE>. As a result, the
|
|
temporary macro <CODE>my_Header</CODE> expands to
|
|
the literal shell name
|
|
<samp>ac_cv_header_stdint_h</samp>. In the second
|
|
invocation, the m4 argument to
|
|
<CODE>MY_CHECK_HEADER</CODE> is
|
|
<CODE>$header</CODE>, and the temporary macro
|
|
<CODE>my_Header</CODE> expands to the indirect shell
|
|
name <samp>$as_my_Header</samp>. During the shell
|
|
execution of the for loop, when <samp>$header</samp>
|
|
contains <samp>inttypes.h</samp>, then
|
|
<samp>$as_my_Header</samp> contains
|
|
<samp>ac_cv_header_inttypes_h</samp>. If this
|
|
script is then run on a platform where all three headers have
|
|
been previously detected, the output of the script will include:</P><P>
|
|
|
|
@smallexample header stdint.h detected header inttypes.h
|
|
detected header stdlib.h detected @end smallexample
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_SET">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="[value]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit shell code to assign the contents of the polymorphic shell
|
|
variable <VAR>var</VAR> to the shell expansion of
|
|
<VAR>value</VAR>. <VAR>value</VAR> is
|
|
not subject to field splitting or file name expansion, so if
|
|
command substitution is used, it may be done with
|
|
<samp>`""`</samp> rather than using an intermediate
|
|
variable (Shell Substitutions). However,
|
|
<VAR>value</VAR> does undergo rescanning for
|
|
additional macro names; behavior is unspecified if late
|
|
expansion results in any shell meta-characters.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_SET_IF">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
<parameter content="[if-set]"/>
|
|
<parameter content="[if-undef]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit a shell conditional statement, which executes
|
|
<VAR>if-set</VAR> if the polymorphic shell variable
|
|
<CODE>var</CODE> is set to any value, and
|
|
<VAR>if-undef</VAR> otherwise.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_VAR_TEST_SET">
|
|
<prototype>
|
|
<parameter content="var"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit a shell statement that results in a successful exit status
|
|
only if the polymorphic shell variable
|
|
<CODE>var</CODE> is set.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_BOURNE_COMPATIBLE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set up the shell to be more compatible with the Bourne shell as
|
|
standardized by Posix, if possible. This may involve setting
|
|
environment variables, or setting options, or similar
|
|
implementation-specific actions. This macro is deprecated,
|
|
since <CODE>AS_INIT</CODE> already invokes it.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_INIT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Initialize the M4sh environment. This macro calls
|
|
<CODE>m4_init</CODE>, then outputs the
|
|
<CODE>#! /bin/sh</CODE> line, a notice about where
|
|
the output was generated from, and code to sanitize the
|
|
environment for the rest of the script. Among other
|
|
initializations, this sets SHELL to the shell chosen to run the
|
|
script (CONFIG_SHELL), and LC_ALL to ensure the C locale.
|
|
Finally, it changes the current diversion to
|
|
<CODE>BODY</CODE>. <CODE>AS_INIT</CODE>
|
|
is called automatically by <CODE>AC_INIT</CODE> and
|
|
<CODE>AT_INIT</CODE>, so shell code in
|
|
<TT>configure</TT>,
|
|
<TT>config.status</TT>, and
|
|
<TT>testsuite</TT> all benefit from a sanitized
|
|
shell environment.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_INIT_GENERATED">
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
<parameter content="[comment]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Emit shell code to start the creation of a subsidiary shell
|
|
script in <VAR>file</VAR>, including changing
|
|
<VAR>file</VAR> to be executable. This macro
|
|
populates the child script with information learned from the
|
|
parent (thus, the emitted code is equivalent in effect, but more
|
|
efficient, than the code output by
|
|
<CODE>AS_INIT</CODE>,
|
|
<CODE>AS_BOURNE_COMPATIBLE</CODE>, and
|
|
<CODE>AS_SHELL_SANITIZE</CODE>). If present,
|
|
<VAR>comment</VAR> is output near the beginning of
|
|
the child, prior to the shell initialization code, and is
|
|
subject to parameter expansion, command substitution, and
|
|
backslash quote removal. The parent script should check the
|
|
exit status after this macro, in case
|
|
<VAR>file</VAR> could not be properly created (for
|
|
example, if the disk was full). If successfully created, the
|
|
parent script can then proceed to append additional M4sh
|
|
constructs into the child script.</P><P>
|
|
|
|
Note that the child script starts life without a log file open,
|
|
so if the parent script uses logging (AS_MESSAGE_LOG_FD), you
|
|
must temporarily disable any attempts to use the log file until
|
|
after emitting code to open a log within the child. On the
|
|
other hand, if the parent script has
|
|
<CODE>AS_MESSAGE_FD</CODE> redirected somewhere
|
|
besides <samp>1</samp>, then the child script
|
|
already has code that copies stdout to that descriptor.
|
|
Currently, the suggested idiom for writing a M4sh shell script
|
|
from within another script is:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
AS_INIT_GENERATED([<VAR>file</VAR>], [[# My child
|
|
script. ]]) || AS_ECHO(["Failed to create child script"]);
|
|
AS_EXIT; @ m4_pushdef([AS_MESSAGE_LOG_FD])dnl cat >>
|
|
"<VAR>file</VAR>" <<\__EOF__ # Code to
|
|
initialize AS_MESSAGE_LOG_FD m4_popdef([AS_MESSAGE_LOG_FD])dnl #
|
|
Additional code __EOF__
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This, however, may change in the future as the M4sh interface is
|
|
stabilized further.</P><P>
|
|
|
|
Also, be aware that use of LINENO within the child script may
|
|
report line numbers relative to their location in the parent
|
|
script, even when using
|
|
<CODE>AS_LINENO_PREPARE</CODE>, if the parent script
|
|
was unable to locate a shell with working LINENO support.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_LINENO_PREPARE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Find a shell that supports the special variable LINENO, which
|
|
contains the number of the currently executing line. This macro
|
|
is automatically invoked by <CODE>AC_INIT</CODE> in
|
|
configure scripts.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_ME_PREPARE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Set up variable as_me to be the basename of the currently
|
|
executing script. This macro is automatically invoked by
|
|
<CODE>AC_INIT</CODE> in configure scripts.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_TMPDIR">
|
|
<prototype>
|
|
<parameter content="prefix"/>
|
|
<parameter content="[dir= $@{TMPDIR:=/tmp@]}"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Create, as safely as possible, a temporary sub-directory
|
|
within <VAR>dir</VAR> with a name starting with
|
|
<VAR>prefix</VAR>. <VAR>prefix</VAR>
|
|
should be 2-4 characters, to make it slightly easier to identify
|
|
the owner of the directory. If <VAR>dir</VAR> is
|
|
omitted, then the value of TMPDIR will be used (defaulting to
|
|
<samp>/tmp</samp>). On success, the name of the
|
|
newly created directory is stored in the shell variable
|
|
<CODE>tmp</CODE>. On error, the script is aborted.</P><P>
|
|
|
|
Typically, this macro is coupled with some exit traps to delete
|
|
the created directory and its contents on exit or interrupt.
|
|
However, there is a slight window between when the directory is
|
|
created and when the name is actually known to the shell, so an
|
|
interrupt at the right moment might leave the temporary
|
|
directory behind. Hence it is important to use a
|
|
<VAR>prefix</VAR> that makes it easier to determine
|
|
if a leftover temporary directory from an interrupted script is
|
|
safe to delete.</P><P>
|
|
|
|
The use of the output variable <samp>$tmp</samp>
|
|
rather than something in the <samp>as_</samp>
|
|
namespace is historical; it has the unfortunate consequence that
|
|
reusing this otherwise common name for any other purpose inside
|
|
your script has the potential to break any cleanup traps
|
|
designed to remove the temporary directory.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_SHELL_SANITIZE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Initialize the shell suitably for
|
|
<CODE>configure</CODE> scripts. This has the effect
|
|
of <CODE>AS_BOURNE_COMPATIBLE</CODE>, and sets some
|
|
other environment variables for predictable results from
|
|
configuration tests. For example, it sets LC_ALL to change to
|
|
the default C locale. . This macro is deprecated, since
|
|
<CODE>AS_INIT</CODE> already invokes it.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_MESSAGE_FD">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
The file descriptor for <samp>checking
|
|
for...</samp> messages and results. By default,
|
|
<CODE>AS_INIT</CODE> sets this to
|
|
<samp>1</samp> for standalone M4sh clients.
|
|
However, <CODE>AC_INIT</CODE> shuffles things around
|
|
to another file descriptor, in order to allow the
|
|
<samp>-q</samp> option of
|
|
<CODE>configure</CODE> to choose whether messages
|
|
should go to the script's standard output or be discarded.</P><P>
|
|
|
|
If you want to display some messages, consider using one of the
|
|
printing macros (Printing Messages) instead. Copies of messages
|
|
output via these macros are also recorded in
|
|
<TT>config.log</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_MESSAGE_LOG_FD">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This must either be empty, or expand to a file descriptor for
|
|
log messages. By default, <CODE>AS_INIT</CODE> sets
|
|
this macro to the empty string for standalone M4sh clients, thus
|
|
disabling logging. However, <CODE>AC_INIT</CODE>
|
|
shuffles things around so that both
|
|
<CODE>configure</CODE> and
|
|
<CODE>config.status</CODE> use
|
|
<TT>config.log</TT> for log messages. Macros that
|
|
run tools, like <CODE>AC_COMPILE_IFELSE</CODE>
|
|
(Running the Compiler), redirect all output to this descriptor.
|
|
You may want to do so if you develop such a low-level macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_ORIGINAL_STDIN_FD">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This must expand to a file descriptor for the original standard
|
|
input. By default, <CODE>AS_INIT</CODE> sets this
|
|
macro to <samp>0</samp> for standalone M4sh clients.
|
|
However, <CODE>AC_INIT</CODE> shuffles things
|
|
around for safety.</P><P>
|
|
|
|
When <CODE>configure</CODE> runs, it may
|
|
accidentally execute an interactive command that has the same
|
|
name as the non-interactive meant to be used or checked. If the
|
|
standard input was the terminal, such interactive programs would
|
|
cause <CODE>configure</CODE> to stop, pending some
|
|
user input. Therefore <CODE>configure</CODE>
|
|
redirects its standard input from <TT>/dev/null</TT>
|
|
during its initialization. This is not normally a problem,
|
|
since <CODE>configure</CODE> normally does not need
|
|
user input.</P><P>
|
|
|
|
In the extreme case where your <TT>configure</TT>
|
|
script really needs to obtain some values from the original
|
|
standard input, you can read them explicitly from
|
|
<CODE>AS_ORIGINAL_STDIN_FD</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DEFUN">
|
|
<prototype>
|
|
<parameter content="name"/>
|
|
<parameter content="[body]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Autoconf macros are defined using the
|
|
<CODE>AC_DEFUN</CODE> macro, which is similar to the
|
|
M4 builtin <CODE>m4_define</CODE> macro; this
|
|
creates a macro named <VAR>name</VAR> and with
|
|
<VAR>body</VAR> as its expansion. In addition to
|
|
defining a macro, <CODE>AC_DEFUN</CODE> adds to it
|
|
some code that is used to constrain the order in which macros
|
|
are called, while avoiding redundant output (Prerequisite
|
|
Macros).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DIAGNOSE">
|
|
<prototype>
|
|
<parameter content="category"/>
|
|
<parameter content="message"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Report <VAR>message</VAR> as a warning (or as an
|
|
error if requested by the user) if warnings of the
|
|
<VAR>category</VAR> are turned on. This macro is
|
|
obsolescent; you are encouraged to use:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_warn([<VAR>category</VAR>],
|
|
[<VAR>message</VAR>])
|
|
</pre></td></tr></table> instead. ,
|
|
for more details, including valid
|
|
<VAR>category</VAR> names.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_WARNING">
|
|
<prototype>
|
|
<parameter content="message"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Report <VAR>message</VAR> as a syntax warning.
|
|
This macro is obsolescent; you are encouraged to use:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> m4_warn([syntax],
|
|
[<VAR>message</VAR>])
|
|
</pre></td></tr></table> instead. ,
|
|
for more details, as well as better finer-grained categories of
|
|
warnings (not all problems have to do with syntax).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FATAL">
|
|
<prototype>
|
|
<parameter content="message"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Report a severe error <VAR>message</VAR>, and have
|
|
<CODE>autoconf</CODE> die. This macro is
|
|
obsolescent; you are encouraged to use:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
m4_fatal([<VAR>message</VAR>])
|
|
</pre></td></tr></table> instead. ,
|
|
for more details.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_REQUIRE">
|
|
<prototype>
|
|
<parameter content="macro-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If the M4 macro <VAR>macro-name</VAR> has not
|
|
already been called, call it (without any arguments). Make sure
|
|
to quote <VAR>macro-name</VAR> with square brackets.
|
|
<VAR>macro-name</VAR> must have been defined using
|
|
<CODE>AC_DEFUN</CODE> or else contain a call to
|
|
<CODE>AC_PROVIDE</CODE> to indicate that it has been
|
|
called.</P><P>
|
|
|
|
<CODE>AC_REQUIRE</CODE> must be used inside a macro
|
|
defined by <CODE>AC_DEFUN</CODE>; it must not be
|
|
called from the top level. Also, it does not make sense to
|
|
require a macro that takes parameters.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_BEFORE">
|
|
<prototype>
|
|
<parameter content="this-macro-name"/>
|
|
<parameter content="called-macro-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Make M4 print a warning message to the standard error output if
|
|
<VAR>called-macro-name</VAR> has already been
|
|
called. <VAR>this-macro-name</VAR> should be the
|
|
name of the macro that is calling
|
|
<CODE>AC_BEFORE</CODE>. The macro
|
|
<VAR>called-macro-name</VAR> must have been defined
|
|
using <CODE>AC_DEFUN</CODE> or else contain a call
|
|
to <CODE>AC_PROVIDE</CODE> to indicate that it has
|
|
been called.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DEFUN_ONCE">
|
|
<prototype>
|
|
<parameter content="macro-name"/>
|
|
<parameter content="macro-body"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Declare macro <VAR>macro-name</VAR> like
|
|
<CODE>AC_DEFUN</CODE> would (Macro Definitions), but
|
|
add additional logic that guarantees that only the first use of
|
|
the macro (whether by direct expansion or
|
|
<CODE>AC_REQUIRE</CODE>) causes an expansion of
|
|
<VAR>macro-body</VAR>; the expansion will occur
|
|
before the start of any enclosing macro defined by
|
|
<CODE>AC_DEFUN</CODE>. Subsequent expansions are
|
|
silently ignored. Generally, it does not make sense for
|
|
<VAR>macro-body</VAR> to use parameters such as
|
|
<CODE>$1</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AU_DEFUN">
|
|
<prototype>
|
|
<parameter content="old-macro"/>
|
|
<parameter content="implementation"/>
|
|
<parameter content="[message]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <VAR>old-macro</VAR> as
|
|
<VAR>implementation</VAR>. The only difference with
|
|
<CODE>AC_DEFUN</CODE> is that the user is warned
|
|
that <VAR>old-macro</VAR> is now obsolete.</P><P>
|
|
|
|
If she then uses <CODE>autoupdate</CODE>, the call
|
|
to <VAR>old-macro</VAR> is replaced by the modern
|
|
<VAR>implementation</VAR>.
|
|
<VAR>message</VAR> should include information on
|
|
what to do after running <CODE>autoupdate</CODE>;
|
|
<CODE>autoupdate</CODE> prints it as a warning, and
|
|
includes it in the updated <TT>configure.ac</TT>
|
|
file.</P><P>
|
|
|
|
The details of this macro are hairy: if
|
|
<CODE>autoconf</CODE> encounters an
|
|
<CODE>AU_DEFUN</CODE>ed macro, all macros inside its
|
|
second argument are expanded as usual. However, when
|
|
<CODE>autoupdate</CODE> is run, only M4 and M4sugar
|
|
macros are expanded here, while all other macros are disabled
|
|
and appear literally in the updated
|
|
<TT>configure.ac</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AU_ALIAS">
|
|
<prototype>
|
|
<parameter content="old-name"/>
|
|
<parameter content="new-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Used if the <VAR>old-name</VAR> is to be replaced
|
|
by a call to <VAR>new-macro</VAR> with the same
|
|
parameters. This happens for example if the macro was renamed.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CANONICAL_BUILD">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Compute the canonical build-system type variable,
|
|
<CODE>build</CODE>, and its three individual parts
|
|
<CODE>build_cpu</CODE>,
|
|
<CODE>build_vendor</CODE>, and
|
|
<CODE>build_os</CODE>.</P><P>
|
|
|
|
If <samp>--build</samp> was specified, then
|
|
<CODE>build</CODE> is the canonicalization of
|
|
<CODE>build_alias</CODE> by
|
|
<CODE>config.sub</CODE>, otherwise it is determined
|
|
by the shell script <CODE>config.guess</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CANONICAL_HOST">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Compute the canonical host-system type variable,
|
|
<CODE>host</CODE>, and its three individual parts
|
|
<CODE>host_cpu</CODE>,
|
|
<CODE>host_vendor</CODE>, and
|
|
<CODE>host_os</CODE>.</P><P>
|
|
|
|
If <samp>--host</samp> was specified, then
|
|
<CODE>host</CODE> is the canonicalization of
|
|
<CODE>host_alias</CODE> by
|
|
<CODE>config.sub</CODE>, otherwise it defaults to
|
|
<CODE>build</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CANONICAL_TARGET">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Compute the canonical target-system type variable,
|
|
<CODE>target</CODE>, and its three individual parts
|
|
<CODE>target_cpu</CODE>,
|
|
<CODE>target_vendor</CODE>, and
|
|
<CODE>target_os</CODE>.</P><P>
|
|
|
|
If <samp>--target</samp> was specified, then
|
|
<CODE>target</CODE> is the canonicalization of
|
|
<CODE>target_alias</CODE> by
|
|
<CODE>config.sub</CODE>, otherwise it defaults to
|
|
<CODE>host</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PRESERVE_HELP_ORDER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
Request an alternate <samp>--help</samp> format, in
|
|
which options of all types appear together, in the order
|
|
defined. Call this macro before any
|
|
<CODE>AC_ARG_ENABLE</CODE> or
|
|
<CODE>AC_ARG_WITH</CODE>.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> Optional Features and Packages:
|
|
<small>...</small> --enable-bar include
|
|
bar --with-foo use foo
|
|
</pre></td></tr></table></P><P>
|
|
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ARG_WITH">
|
|
<prototype>
|
|
<parameter content="package"/>
|
|
<parameter content="help-string"/>
|
|
<parameter content="@ [action-if-given]"/>
|
|
<parameter content="[action-if-not-given]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If the user gave <CODE>configure</CODE> the option
|
|
<samp>--with-<VAR>package</VAR></samp>
|
|
or
|
|
<samp>--without-<VAR>package</VAR></samp>,
|
|
run shell commands <VAR>action-if-given</VAR>. If
|
|
neither option was given, run shell commands
|
|
<VAR>action-if-not-given</VAR>. The name
|
|
<VAR>package</VAR> indicates another software
|
|
package that this program should work with. It should consist
|
|
only of alphanumeric characters, dashes, plus signs, and dots.</P><P>
|
|
|
|
The option's argument is available to the shell commands
|
|
<VAR>action-if-given</VAR> in the shell variable
|
|
<CODE>withval</CODE>, which is actually just the
|
|
value of the shell variable named
|
|
<CODE>with_<VAR>package</VAR></CODE>,
|
|
with any non-alphanumeric characters in
|
|
<VAR>package</VAR> changed into
|
|
<samp>_</samp>. You may use that variable instead,
|
|
if you wish.</P><P>
|
|
|
|
The argument <VAR>help-string</VAR> is a description
|
|
of the option that looks like this:
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> --with-readline support
|
|
fancy command line editing
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<VAR>help-string</VAR> may be more than one line
|
|
long, if more detail is needed. Just make sure the columns line
|
|
up in <samp>configure --help</samp>. Avoid tabs in
|
|
the help string. The easiest way to provide the proper leading
|
|
whitespace is to format your <VAR>help-string</VAR>
|
|
with the macro <CODE>AS_HELP_STRING</CODE> (Pretty
|
|
Help Strings).</P><P>
|
|
|
|
The following example shows how to use the
|
|
<CODE>AC_ARG_WITH</CODE> macro in a common
|
|
situation. You want to let the user decide whether to enable
|
|
support for an external library (e.g., the readline library); if
|
|
the user specified neither
|
|
<samp>--with-readline</samp> nor
|
|
<samp>--without-readline</samp>, you want to enable
|
|
support for readline only if the library is available on the
|
|
system.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ARG_WITH([readline],
|
|
[AS_HELP_STRING([--with-readline], [support fancy command
|
|
line editing @@<:@@default=check@@:>@@])], [],
|
|
[with_readline=check])</P><P>
|
|
|
|
LIBREADLINE= AS_IF([test "x$with_readline" != xno],
|
|
[AC_CHECK_LIB([readline], [main], [AC_SUBST([LIBREADLINE],
|
|
["-lreadline -lncurses"]) AC_DEFINE([HAVE_LIBREADLINE],
|
|
[1], [Define if you have libreadline]) ],
|
|
[if test "x$with_readline" != xcheck; then
|
|
AC_MSG_FAILURE( [--with-readline was given, but test
|
|
for readline failed]) fi ], -lncurses)])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The next example shows how to use
|
|
<CODE>AC_ARG_WITH</CODE> to give the user the
|
|
possibility to enable support for the readline library, in case
|
|
it is still experimental and not well tested, and is therefore
|
|
disabled by default.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ARG_WITH([readline],
|
|
[AS_HELP_STRING([--with-readline], [enable experimental
|
|
support for readline])], [], [with_readline=no])</P><P>
|
|
|
|
LIBREADLINE= AS_IF([test "x$with_readline" != xno],
|
|
[AC_CHECK_LIB([readline], [main], [AC_SUBST([LIBREADLINE],
|
|
["-lreadline -lncurses"]) AC_DEFINE([HAVE_LIBREADLINE],
|
|
[1], [Define if you have libreadline]) ],
|
|
[AC_MSG_FAILURE( [--with-readline was given, but test for
|
|
readline failed])], [-lncurses])])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The last example shows how to use
|
|
<CODE>AC_ARG_WITH</CODE> to give the user the
|
|
possibility to disable support for the readline library, given
|
|
that it is an important feature and that it should be enabled by
|
|
default.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ARG_WITH([readline],
|
|
[AS_HELP_STRING([--without-readline], [disable support for
|
|
readline])], [], [with_readline=yes])</P><P>
|
|
|
|
LIBREADLINE= AS_IF([test "x$with_readline" != xno],
|
|
[AC_CHECK_LIB([readline], [main], [AC_SUBST([LIBREADLINE],
|
|
["-lreadline -lncurses"]) AC_DEFINE([HAVE_LIBREADLINE],
|
|
[1], [Define if you have libreadline]) ],
|
|
[AC_MSG_FAILURE( [readline test failed
|
|
(--without-readline to disable)])], [-lncurses])])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
These three examples can be easily adapted to the case where
|
|
<CODE>AC_ARG_ENABLE</CODE> should be preferred to
|
|
<CODE>AC_ARG_WITH</CODE> (see Package Options).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ARG_ENABLE">
|
|
<prototype>
|
|
<parameter content="feature"/>
|
|
<parameter content="help-string"/>
|
|
<parameter content="@ [action-if-given]"/>
|
|
<parameter content="[action-if-not-given]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If the user gave <CODE>configure</CODE> the option
|
|
<samp>--enable-<VAR>feature</VAR></samp>
|
|
or
|
|
<samp>--disable-<VAR>feature</VAR></samp>,
|
|
run shell commands <VAR>action-if-given</VAR>. If
|
|
neither option was given, run shell commands
|
|
<VAR>action-if-not-given</VAR>. The name
|
|
<VAR>feature</VAR> indicates an optional user-level
|
|
facility. It should consist only of alphanumeric characters,
|
|
dashes, plus signs, and dots.</P><P>
|
|
|
|
The option's argument is available to the shell commands
|
|
<VAR>action-if-given</VAR> in the shell variable
|
|
<CODE>enableval</CODE>, which is actually just the
|
|
value of the shell variable named
|
|
<CODE>enable_<VAR>feature</VAR></CODE>,
|
|
with any non-alphanumeric characters in
|
|
<VAR>feature</VAR> changed into
|
|
<samp>_</samp>. You may use that variable instead,
|
|
if you wish. The <VAR>help-string</VAR> argument is
|
|
like that of <CODE>AC_ARG_WITH</CODE> (External
|
|
Software).</P><P>
|
|
|
|
You should format your <VAR>help-string</VAR> with
|
|
the macro <CODE>AS_HELP_STRING</CODE> (Pretty Help
|
|
Strings).</P><P>
|
|
|
|
See the examples suggested with the definition of
|
|
<CODE>AC_ARG_WITH</CODE> (External Software) to get
|
|
an idea of possible applications of
|
|
<CODE>AC_ARG_ENABLE</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AS_HELP_STRING">
|
|
<prototype>
|
|
<parameter content="left-hand-side"/>
|
|
<parameter content="right-hand-side @ [indent-column= 26]"/>
|
|
<parameter content="[wrap-column= 79]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
Expands into a help string that looks pretty when the user
|
|
executes <samp>configure --help</samp>. It is
|
|
typically used in <CODE>AC_ARG_WITH</CODE> (External
|
|
Software) or <CODE>AC_ARG_ENABLE</CODE> (Package
|
|
Options). The following example makes this clearer.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_ARG_WITH([foo],
|
|
[AS_HELP_STRING([--with-foo], [use foo (default is no)])],
|
|
[use_foo=$withval], [use_foo=no])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Then the last few lines of <samp>configure
|
|
--help</samp> appear like this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> --enable and --with options
|
|
recognized: --with-foo use foo (default is no)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Macro expansion is performed on the first argument. However,
|
|
the second argument of <CODE>AS_HELP_STRING</CODE>
|
|
is treated as a whitespace separated list of text to be
|
|
reformatted, and is not subject to macro expansion. Since it is
|
|
not expanded, it should not be double quoted. , for a more
|
|
detailed explanation.</P><P>
|
|
|
|
The <CODE>AS_HELP_STRING</CODE> macro is
|
|
particularly helpful when the
|
|
<VAR>left-hand-side</VAR> and/or
|
|
<VAR>right-hand-side</VAR> are composed of macro
|
|
arguments, as shown in the following example. Be aware that
|
|
<VAR>left-hand-side</VAR> may not expand to
|
|
unbalanced quotes, although quadrigraphs can be used.</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_DEFUN([MY_ARG_WITH],
|
|
[AC_ARG_WITH(m4_translit([[$1]], [_], [-]),
|
|
[AS_HELP_STRING([--with-m4_translit([$1], [_], [-])],
|
|
[use $1 (default is $2)])], [use_[]$1=$withval],
|
|
[use_[]$1=$2])]) MY_ARG_WITH([a_b], [no])
|
|
</pre></td></tr></table> Here, the last
|
|
few lines of <samp>configure --help</samp> will
|
|
include:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> --enable and --with options
|
|
recognized: --with-a-b use a_b (default is no)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The parameters <VAR>indent-column</VAR> and
|
|
<VAR>wrap-column</VAR> were introduced in Autoconf
|
|
2.62. Generally, they should not be specified; they exist for
|
|
fine-tuning of the wrapping.
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AS_HELP_STRING([--option],
|
|
[description of option]) --option description
|
|
of option AS_HELP_STRING([--option], [description of option],
|
|
[15], [30]) --option description of option
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DISABLE_OPTION_CHECKING">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
</P><P>
|
|
|
|
By default, disable warnings related to any unrecognized
|
|
<samp>--with-<VAR>package</VAR></samp>
|
|
or
|
|
<samp>--enable-<VAR>feature</VAR></samp>
|
|
options. This is implied by
|
|
<CODE>AC_CONFIG_SUBDIRS</CODE>.</P><P>
|
|
|
|
The installer can override this behavior by passing
|
|
<samp>--enable-option-checking</samp> (enable
|
|
warnings) or
|
|
<samp>--enable-option-checking=fatal</samp> (enable
|
|
errors) to <CODE>configure</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ARG_PROGRAM">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Place in output variable
|
|
<CODE>program_transform_name</CODE> a sequence of
|
|
<CODE>sed</CODE> commands for changing the names of
|
|
installed programs.</P><P>
|
|
|
|
If any of the options described below are given to
|
|
<CODE>configure</CODE>, program names are
|
|
transformed accordingly. Otherwise, if
|
|
<CODE>AC_CANONICAL_TARGET</CODE> has been called and
|
|
a <samp>--target</samp> value is given, the target
|
|
type followed by a dash is used as a prefix. Otherwise, no
|
|
program name transformation is done.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_AIX">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is a platform-specific subset of
|
|
<CODE>AC_USE_SYSTEM_EXTENSIONS</CODE>
|
|
(AC_USE_SYSTEM_EXTENSIONS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ALLOCA">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_FUNC_ALLOCA</CODE>
|
|
(AC_FUNC_ALLOCA).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ARG_ARRAY">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Removed because of limited usefulness.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_CROSS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is obsolete; it does nothing.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_C_LONG_DOUBLE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports a working <CODE>long
|
|
double</CODE> type with more range or precision than the
|
|
<CODE>double</CODE> type, define
|
|
<CODE>HAVE_LONG_DOUBLE</CODE>.</P><P>
|
|
|
|
You should use <CODE>AC_TYPE_LONG_DOUBLE</CODE> or
|
|
<CODE>AC_TYPE_LONG_DOUBLE_WIDER</CODE> instead. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CANONICAL_SYSTEM">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine the system type and set output variables to the names
|
|
of the canonical system types. , for details about the
|
|
variables this macro sets.</P><P>
|
|
|
|
The user is encouraged to use either
|
|
<CODE>AC_CANONICAL_BUILD</CODE>, or
|
|
<CODE>AC_CANONICAL_HOST</CODE>, or
|
|
<CODE>AC_CANONICAL_TARGET</CODE>, depending on the
|
|
needs. Using <CODE>AC_CANONICAL_TARGET</CODE> is
|
|
enough to run the two other macros (Canonicalizing).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHAR_UNSIGNED">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_C_CHAR_UNSIGNED</CODE>
|
|
(AC_C_CHAR_UNSIGNED).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CHECKING">
|
|
<prototype>
|
|
<parameter content="feature-description"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_MSG_NOTICE([checking
|
|
<VAR>feature-description</VAR><small>...</small>]
|
|
</pre></td></tr></table></P><P>
|
|
|
|
.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_COMPILE_CHECK">
|
|
<prototype>
|
|
<parameter content="echo-text"/>
|
|
<parameter content="includes"/>
|
|
<parameter content="@ function-body"/>
|
|
<parameter content="action-if-true"/>
|
|
<parameter content="[action-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This is an obsolete version of
|
|
<CODE>AC_TRY_COMPILE</CODE> itself replaced by
|
|
<CODE>AC_COMPILE_IFELSE</CODE> (Running the
|
|
Compiler), with the addition that it prints <samp>checking
|
|
for <VAR>echo-text</VAR></samp> to the
|
|
standard output first, if <VAR>echo-text</VAR> is
|
|
non-empty. Use <CODE>AC_MSG_CHECKING</CODE> and
|
|
<CODE>AC_MSG_RESULT</CODE> instead to print messages
|
|
(Printing Messages).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONST">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_C_CONST</CODE> (AC_C_CONST).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CROSS_CHECK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as <CODE>AC_C_CROSS</CODE>, which is obsolete
|
|
too, and does nothing <CODE>:-)</CODE>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CYGWIN">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Check for the Cygwin environment in which case the shell
|
|
variable <CODE>CYGWIN</CODE> is set to
|
|
<samp>yes</samp>. Don't use this macro, the
|
|
dignified means to check the nature of the host is using
|
|
<CODE>AC_CANONICAL_HOST</CODE> (Canonicalizing). As
|
|
a matter of fact this macro is defined as:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
AC_REQUIRE([AC_CANONICAL_HOST])[]dnl case $host_os in *cygwin*
|
|
) CYGWIN=yes;; * ) CYGWIN=no;; esac
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Beware that the variable CYGWIN has a special meaning when
|
|
running Cygwin, and should not be changed. That's yet another
|
|
reason not to use this macro.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DECL_SYS_SIGLIST">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_DECLS([sys_siglist], [],
|
|
[], [#include <signal.h> /* NetBSD declares sys_siglist in
|
|
unistd.h. */ #ifdef HAVE_UNISTD_H # include <unistd.h>
|
|
#endif ]) </pre></td></tr></table></P><P>
|
|
|
|
.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DECL_YYTEXT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Does nothing, now integrated in
|
|
<CODE>AC_PROG_LEX</CODE> (AC_PROG_LEX).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DIR_HEADER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Like calling <CODE>AC_FUNC_CLOSEDIR_VOID</CODE>
|
|
(AC_FUNC_CLOSEDIR_VOID) and
|
|
<CODE>AC_HEADER_DIRENT</CODE> (AC_HEADER_DIRENT),
|
|
but defines a different set of C preprocessor macros to indicate
|
|
which header file is found:</P><P>
|
|
|
|
@multitable {<TT>sys/ndir.h</TT>} {Old Symbol}
|
|
{<CODE>HAVE_SYS_NDIR_H</CODE>} <LI> Header
|
|
@tab Old Symbol @tab New Symbol <LI>
|
|
<TT>dirent.h</TT> @tab
|
|
<CODE>DIRENT</CODE> @tab
|
|
<CODE>HAVE_DIRENT_H</CODE> <LI>
|
|
<TT>sys/ndir.h</TT> @tab
|
|
<CODE>SYSNDIR</CODE> @tab
|
|
<CODE>HAVE_SYS_NDIR_H</CODE> <LI>
|
|
<TT>sys/dir.h</TT> @tab
|
|
<CODE>SYSDIR</CODE> @tab
|
|
<CODE>HAVE_SYS_DIR_H</CODE> <LI>
|
|
<TT>ndir.h</TT> @tab
|
|
<CODE>NDIR</CODE> @tab
|
|
<CODE>HAVE_NDIR_H</CODE> @end multitable
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_DYNIX_SEQ">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If on DYNIX/ptx, add <samp>-lseq</samp> to output
|
|
variable <CODE>LIBS</CODE>. This macro used to be
|
|
defined as</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_LIB([seq], [getmntent],
|
|
[LIBS="-lseq $LIBS"])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
now it is just <CODE>AC_FUNC_GETMNTENT</CODE>
|
|
(AC_FUNC_GETMNTENT).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_EXEEXT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Defined the output variable <CODE>EXEEXT</CODE>
|
|
based on the output of the compiler, which is now done
|
|
automatically. Typically set to empty string if Posix and
|
|
<samp>.exe</samp> if a DOS variant.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_EMXOS2">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Similar to <CODE>AC_CYGWIN</CODE> but checks for
|
|
the EMX environment on OS/2 and sets
|
|
<CODE>EMXOS2</CODE>. Don't use this macro, the
|
|
dignified means to check the nature of the host is using
|
|
<CODE>AC_CANONICAL_HOST</CODE> (Canonicalizing).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ENABLE">
|
|
<prototype>
|
|
<parameter content="feature"/>
|
|
<parameter content="action-if-given"/>
|
|
<parameter content="@ [action-if-not-given]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This is an obsolete version of
|
|
<CODE>AC_ARG_ENABLE</CODE> that does not support
|
|
providing a help string (AC_ARG_ENABLE).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ERROR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_MSG_ERROR</CODE>
|
|
(AC_MSG_ERROR).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FIND_X">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PATH_X</CODE> (AC_PATH_X).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FIND_XTRA">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PATH_XTRA</CODE>
|
|
(AC_PATH_XTRA).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FOREACH">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>m4_foreach_w</CODE>
|
|
(m4_foreach_w).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_CHECK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_FUNC</CODE>
|
|
(AC_CHECK_FUNC).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_SETVBUF_REVERSED">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Do nothing. Formerly, this macro checked whether
|
|
<CODE>setvbuf</CODE> takes the buffering type as its
|
|
second argument and the buffer pointer as the third, instead of
|
|
the other way around, and defined
|
|
<CODE>SETVBUF_REVERSED</CODE>. However, the last
|
|
systems to have the problem were those based on SVR2, which
|
|
became obsolete in 1987, and the macro is no longer needed.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_FUNC_WAIT3">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>wait3</CODE> is found and fills in the
|
|
contents of its third argument (a <samp>struct rusage
|
|
*</samp>), which HP-UX does not do, define
|
|
<CODE>HAVE_WAIT3</CODE>.</P><P>
|
|
|
|
These days portable programs should use
|
|
<CODE>waitpid</CODE>, not
|
|
<CODE>wait3</CODE>, as
|
|
<CODE>wait3</CODE> has been removed from Posix.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_GCC_TRADITIONAL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PROG_GCC_TRADITIONAL</CODE>
|
|
(AC_PROG_GCC_TRADITIONAL).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_GETGROUPS_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_TYPE_GETGROUPS</CODE>
|
|
(AC_TYPE_GETGROUPS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_GETLOADAVG">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_FUNC_GETLOADAVG</CODE>
|
|
(AC_FUNC_GETLOADAVG).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_GNU_SOURCE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is a platform-specific subset of
|
|
<CODE>AC_USE_SYSTEM_EXTENSIONS</CODE>
|
|
(AC_USE_SYSTEM_EXTENSIONS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HAVE_FUNCS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_FUNCS</CODE>
|
|
(AC_CHECK_FUNCS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HAVE_HEADERS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_HEADERS</CODE>
|
|
(AC_CHECK_HEADERS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HAVE_LIBRARY">
|
|
<prototype>
|
|
<parameter content="library"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
<parameter content="[other-libraries]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is equivalent to calling
|
|
<CODE>AC_CHECK_LIB</CODE> with a
|
|
<VAR>function</VAR> argument of
|
|
<CODE>main</CODE>. In addition,
|
|
<VAR>library</VAR> can be written as any of
|
|
<samp>foo</samp>, <samp>-lfoo</samp>, or
|
|
<samp>libfoo.a</samp>. In all of those cases, the
|
|
compiler is passed <samp>-lfoo</samp>. However,
|
|
<VAR>library</VAR> cannot be a shell variable; it
|
|
must be a literal name. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HAVE_POUNDBANG">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_SYS_INTERPRETER</CODE>
|
|
(AC_SYS_INTERPRETER).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_CHECK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_HEADER</CODE>
|
|
(AC_CHECK_HEADER).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HEADER_EGREP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_EGREP_HEADER</CODE>
|
|
(AC_EGREP_HEADER).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_HELP_STRING">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AS_HELP_STRING</CODE>
|
|
(AS_HELP_STRING).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_INLINE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_C_INLINE</CODE> (AC_C_INLINE).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_INT_16_BITS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C type <CODE>int</CODE> is 16 bits wide,
|
|
define <CODE>INT_16_BITS</CODE>. Use
|
|
<samp>AC_CHECK_SIZEOF(int)</samp> instead
|
|
(AC_CHECK_SIZEOF).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_IRIX_SUN">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If on IRIX (Silicon Graphics Unix), add
|
|
<samp>-lsun</samp> to output
|
|
<CODE>LIBS</CODE>. If you were using it to get
|
|
<CODE>getmntent</CODE>, use
|
|
<CODE>AC_FUNC_GETMNTENT</CODE> instead. If you used
|
|
it for the NIS versions of the password and group functions, use
|
|
<samp>AC_CHECK_LIB(sun, getpwnam)</samp>. Up to
|
|
Autoconf 2.13, it used to be</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_LIB([sun], [getmntent],
|
|
[LIBS="-lsun $LIBS"])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
now it is defined as</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_FUNC_GETMNTENT
|
|
AC_CHECK_LIB([sun], [getpwnam])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
See AC_FUNC_GETMNTENT and AC_CHECK_LIB.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ISC_POSIX">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro adds <samp>-lcposix</samp> to output
|
|
variable <CODE>LIBS</CODE> if necessary for Posix
|
|
facilities. Sun dropped support for the obsolete INTERACTIVE
|
|
Systems Corporation Unix on 2006-07-23. New programs need not
|
|
use this macro. It is implemented as
|
|
<CODE>AC_SEARCH_LIBS([strerror], [cposix])</CODE>
|
|
(AC_SEARCH_LIBS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_C">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as <samp>AC_LANG([C])</samp> (AC_LANG).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_CPLUSPLUS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as <samp>AC_LANG([C++])</samp> (AC_LANG).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_FORTRAN77">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as <samp>AC_LANG([Fortran 77])</samp>
|
|
(AC_LANG).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_RESTORE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Select the <VAR>language</VAR> that is saved on the
|
|
top of the stack, as set by
|
|
<CODE>AC_LANG_SAVE</CODE>, remove it from the stack,
|
|
and call
|
|
<CODE>AC_LANG(<VAR>language</VAR>)</CODE>.
|
|
, for the preferred way to change languages.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LANG_SAVE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Remember the current language (as set by
|
|
<CODE>AC_LANG</CODE>) on a stack. The current
|
|
language does not change. <CODE>AC_LANG_PUSH</CODE>
|
|
is preferred (AC_LANG_PUSH).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LINK_FILES">
|
|
<prototype>
|
|
<parameter content="source..."/>
|
|
<parameter content="dest..."/>
|
|
</prototype>
|
|
<synopsis>
|
|
This is an obsolete version of
|
|
<CODE>AC_CONFIG_LINKS</CODE> (AC_CONFIG_LINKS. An
|
|
updated version of:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_LINK_FILES(config/$machine.h
|
|
config/$obj_format.h, host.h object.h)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre>
|
|
AC_CONFIG_LINKS([host.h:config/$machine.h
|
|
object.h:config/$obj_format.h])
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LN_S">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PROG_LN_S</CODE>
|
|
(AC_PROG_LN_S).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LONG_64_BITS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>LONG_64_BITS</CODE> if the C type
|
|
<CODE>long int</CODE> is 64 bits wide. Use the
|
|
generic macro <samp>AC_CHECK_SIZEOF([long
|
|
int])</samp> instead (AC_CHECK_SIZEOF).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LONG_DOUBLE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the C compiler supports a working <CODE>long
|
|
double</CODE> type with more range or precision than the
|
|
<CODE>double</CODE> type, define
|
|
<CODE>HAVE_LONG_DOUBLE</CODE>.</P><P>
|
|
|
|
You should use <CODE>AC_TYPE_LONG_DOUBLE</CODE> or
|
|
<CODE>AC_TYPE_LONG_DOUBLE_WIDER</CODE> instead. .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_LONG_FILE_NAMES">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_SYS_LONG_FILE_NAMES
|
|
</pre></td></tr></table> .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MAJOR_HEADER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_HEADER_MAJOR</CODE>
|
|
(AC_HEADER_MAJOR).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MEMORY_H">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Used to define <CODE>NEED_MEMORY_H</CODE> if the
|
|
<CODE>mem</CODE> functions were defined in
|
|
<TT>memory.h</TT>. Today it is equivalent to
|
|
<samp>AC_CHECK_HEADERS([memory.h])</samp>
|
|
(AC_CHECK_HEADERS). Adjust your code to depend upon
|
|
<CODE>HAVE_MEMORY_H</CODE>, not
|
|
<CODE>NEED_MEMORY_H</CODE>; see Standard Symbols.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MINGW32">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Similar to <CODE>AC_CYGWIN</CODE> but checks for
|
|
the MinGW compiler environment and sets
|
|
<CODE>MINGW32</CODE>. Don't use this macro, the
|
|
dignified means to check the nature of the host is using
|
|
<CODE>AC_CANONICAL_HOST</CODE> (Canonicalizing).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MINIX">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is a platform-specific subset of
|
|
<CODE>AC_USE_SYSTEM_EXTENSIONS</CODE>
|
|
(AC_USE_SYSTEM_EXTENSIONS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MINUS_C_MINUS_O">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PROG_CC_C_O</CODE>
|
|
(AC_PROG_CC_C_O).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MMAP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_FUNC_MMAP</CODE>
|
|
(AC_FUNC_MMAP).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_MODE_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_TYPE_MODE_T</CODE>
|
|
(AC_TYPE_MODE_T).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_OBJEXT">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Defined the output variable <CODE>OBJEXT</CODE>
|
|
based on the output of the compiler, after .c files have been
|
|
excluded. Typically set to <samp>o</samp> if Posix,
|
|
<samp>obj</samp> if a DOS variant. Now the compiler
|
|
checking macros handle this automatically.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_OBSOLETE">
|
|
<prototype>
|
|
<parameter content="this-macro-name"/>
|
|
<parameter content="[suggestion]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Make M4 print a message to the standard error output warning
|
|
that <VAR>this-macro-name</VAR> is obsolete, and
|
|
giving the file and line number where it was called.
|
|
<VAR>this-macro-name</VAR> should be the name of the
|
|
macro that is calling <CODE>AC_OBSOLETE</CODE>. If
|
|
<VAR>suggestion</VAR> is given, it is printed at the
|
|
end of the warning message; for example, it can be a suggestion
|
|
for what to use instead of
|
|
<VAR>this-macro-name</VAR>.</P><P>
|
|
|
|
For instance</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_OBSOLETE([$0], [; use
|
|
AC_CHECK_HEADERS(unistd.h) instead])dnl
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You are encouraged to use <CODE>AU_DEFUN</CODE>
|
|
instead, since it gives better services to the user (AU_DEFUN).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_OFF_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_TYPE_OFF_T</CODE>
|
|
(AC_TYPE_OFF_T).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_OUTPUT_COMMANDS">
|
|
<prototype>
|
|
<parameter content="extra-cmds"/>
|
|
<parameter content="[init-cmds]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Specify additional shell commands to run at the end of
|
|
<TT>config.status</TT>, and shell commands to
|
|
initialize any variables from
|
|
<CODE>configure</CODE>. This macro may be called
|
|
multiple times. It is obsolete, replaced by
|
|
<CODE>AC_CONFIG_COMMANDS</CODE>
|
|
(AC_CONFIG_COMMANDS).</P><P>
|
|
|
|
Here is an unrealistic example:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> 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])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Aside from the fact that
|
|
<CODE>AC_CONFIG_COMMANDS</CODE> requires an
|
|
additional key, an important difference is that
|
|
<CODE>AC_OUTPUT_COMMANDS</CODE> is quoting its
|
|
arguments twice, unlike
|
|
<CODE>AC_CONFIG_COMMANDS</CODE>. This means that
|
|
<CODE>AC_CONFIG_COMMANDS</CODE> can safely be given
|
|
macro calls as arguments:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CONFIG_COMMANDS(foo, [my_FOO()])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Conversely, where one level of quoting was enough for literal
|
|
strings with <CODE>AC_OUTPUT_COMMANDS</CODE>, you
|
|
need two with <CODE>AC_CONFIG_COMMANDS</CODE>. The
|
|
following lines are equivalent:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group AC_OUTPUT_COMMANDS([echo
|
|
"Square brackets: []"]) AC_CONFIG_COMMANDS([default], [[echo
|
|
"Square brackets: []"]]) @end group
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PID_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_TYPE_PID_T</CODE>
|
|
(AC_TYPE_PID_T).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PREFIX">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PREFIX_PROGRAM</CODE>
|
|
(AC_PREFIX_PROGRAM).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROGRAMS_CHECK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_PROGS</CODE>
|
|
(AC_CHECK_PROGS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROGRAMS_PATH">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PATH_PROGS</CODE>
|
|
(AC_PATH_PROGS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROGRAM_CHECK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_PROG</CODE>
|
|
(AC_CHECK_PROG).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROGRAM_EGREP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_EGREP_CPP</CODE>
|
|
(AC_EGREP_CPP).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_PROGRAM_PATH">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PATH_PROG</CODE>
|
|
(AC_PATH_PROG).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_REMOTE_TAPE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Removed because of limited usefulness.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_RESTARTABLE_SYSCALLS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was renamed
|
|
<CODE>AC_SYS_RESTARTABLE_SYSCALLS</CODE>. However,
|
|
these days portable programs should use
|
|
<CODE>sigaction</CODE> with
|
|
<CODE>SA_RESTART</CODE> if they want restartable
|
|
system calls. They should not rely on
|
|
<CODE>HAVE_RESTARTABLE_SYSCALLS</CODE>, since
|
|
nowadays whether a system call is restartable is a dynamic
|
|
issue, not a configuration-time issue.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_RETSIGTYPE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_TYPE_SIGNAL</CODE>
|
|
(AC_TYPE_SIGNAL), which itself is obsolete when assuming C89 or
|
|
better.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_RSH">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Removed because of limited usefulness.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SCO_INTL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If on SCO Unix, add <samp>-lintl</samp> to output
|
|
variable <CODE>LIBS</CODE>. This macro used to do
|
|
this:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_LIB([intl], [strftime],
|
|
[LIBS="-lintl $LIBS"])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Now it just calls <CODE>AC_FUNC_STRFTIME</CODE>
|
|
instead (AC_FUNC_STRFTIME).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SETVBUF_REVERSED">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_FUNC_SETVBUF_REVERSED
|
|
</pre></td></tr></table> .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SET_MAKE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_PROG_MAKE_SET</CODE>
|
|
(AC_PROG_MAKE_SET).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SIZEOF_TYPE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_SIZEOF</CODE>
|
|
(AC_CHECK_SIZEOF).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SIZE_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_TYPE_SIZE_T</CODE>
|
|
(AC_TYPE_SIZE_T).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STAT_MACROS_BROKEN">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_HEADER_STAT</CODE>
|
|
(AC_HEADER_STAT).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STDC_HEADERS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_HEADER_STDC</CODE>
|
|
(AC_HEADER_STDC).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRCOLL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_FUNC_STRCOLL</CODE>
|
|
(AC_FUNC_STRCOLL).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRUCT_ST_BLKSIZE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>struct stat</CODE> contains an
|
|
<CODE>st_blksize</CODE> member, define
|
|
<CODE>HAVE_STRUCT_STAT_ST_BLKSIZE</CODE>. The
|
|
former name, <CODE>HAVE_ST_BLKSIZE</CODE> is to be
|
|
avoided, as its support will cease in the future. This macro is
|
|
obsoleted, and should be replaced by</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_MEMBERS([struct
|
|
stat.st_blksize])
|
|
</pre></td></tr></table> .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_STRUCT_ST_RDEV">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If <CODE>struct stat</CODE> contains an
|
|
<CODE>st_rdev</CODE> member, define
|
|
<CODE>HAVE_STRUCT_STAT_ST_RDEV</CODE>. The former
|
|
name for this macro, <CODE>HAVE_ST_RDEV</CODE>, is
|
|
to be avoided as it will cease to be supported in the future.
|
|
Actually, even the new macro is obsolete and should be replaced
|
|
by: <TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_CHECK_MEMBERS([struct
|
|
stat.st_rdev]) </pre></td></tr></table>
|
|
.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ST_BLKSIZE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_MEMBERS</CODE>
|
|
(AC_CHECK_MEMBERS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ST_BLOCKS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_STRUCT_ST_BLOCKS</CODE>
|
|
(AC_STRUCT_ST_BLOCKS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_ST_RDEV">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_CHECK_MEMBERS</CODE>
|
|
(AC_CHECK_MEMBERS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SYS_RESTARTABLE_SYSCALLS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
If the system automatically restarts a system call that is
|
|
interrupted by a signal, define
|
|
<CODE>HAVE_RESTARTABLE_SYSCALLS</CODE>. This macro
|
|
does not check whether system calls are restarted in
|
|
general---it checks whether a signal handler installed with
|
|
<CODE>signal</CODE> (but not
|
|
<CODE>sigaction</CODE>) causes system calls to be
|
|
restarted. It does not check whether system calls can be
|
|
restarted when interrupted by signals that have no handler.</P><P>
|
|
|
|
These days portable programs should use
|
|
<CODE>sigaction</CODE> with
|
|
<CODE>SA_RESTART</CODE> if they want restartable
|
|
system calls. They should not rely on
|
|
<CODE>HAVE_RESTARTABLE_SYSCALLS</CODE>, since
|
|
nowadays whether a system call is restartable is a dynamic
|
|
issue, not a configuration-time issue.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_SYS_SIGLIST_DECLARED">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was renamed
|
|
<CODE>AC_DECL_SYS_SIGLIST</CODE>. However, even
|
|
that name is obsolete, as the same functionality is now acheived
|
|
via <CODE>AC_CHECK_DECLS</CODE> (AC_CHECK_DECLS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TEST_CPP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was renamed <CODE>AC_TRY_CPP</CODE>,
|
|
which in turn was replaced by
|
|
<CODE>AC_PREPROC_IFELSE</CODE> (AC_PREPROC_IFELSE).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TEST_PROGRAM">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was renamed <CODE>AC_TRY_RUN</CODE>,
|
|
which in turn was replaced by
|
|
<CODE>AC_RUN_IFELSE</CODE> (AC_RUN_IFELSE).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TIMEZONE">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_STRUCT_TIMEZONE</CODE>
|
|
(AC_STRUCT_TIMEZONE).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TIME_WITH_SYS_TIME">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_HEADER_TIME</CODE>
|
|
(AC_HEADER_TIME).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TRY_COMPILE">
|
|
<prototype>
|
|
<parameter content="includes"/>
|
|
<parameter content="function-body"/>
|
|
<parameter content="@ [action-if-true]"/>
|
|
<parameter content="[action-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_COMPILE_IFELSE(
|
|
[AC_LANG_PROGRAM([[<VAR>includes</VAR>]],
|
|
[[<VAR>function-body</VAR>]])],
|
|
[<VAR>action-if-true</VAR>],
|
|
[<VAR>action-if-false</VAR>])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
.</P><P>
|
|
|
|
This macro double quotes both <VAR>includes</VAR>
|
|
and <VAR>function-body</VAR>.</P><P>
|
|
|
|
For C and C++, <VAR>includes</VAR> is any
|
|
<CODE>#include</CODE> statements needed by the code
|
|
in <VAR>function-body</VAR>
|
|
(<VAR>includes</VAR> is ignored if the currently
|
|
selected language is Fortran or Fortran 77). The compiler and
|
|
compilation flags are determined by the current language
|
|
(Language Choice).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TRY_CPP">
|
|
<prototype>
|
|
<parameter content="input"/>
|
|
<parameter content="[action-if-true]"/>
|
|
<parameter content="[action-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_PREPROC_IFELSE(
|
|
[AC_LANG_SOURCE([[<VAR>input</VAR>]])],
|
|
[<VAR>action-if-true</VAR>],
|
|
[<VAR>action-if-false</VAR>])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
.</P><P>
|
|
|
|
This macro double quotes the <VAR>input</VAR>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TRY_LINK">
|
|
<prototype>
|
|
<parameter content="includes"/>
|
|
<parameter content="function-body"/>
|
|
<parameter content="@ [action-if-true]"/>
|
|
<parameter content="[action-if-false]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_LINK_IFELSE(
|
|
[AC_LANG_PROGRAM([[<VAR>includes</VAR>]],
|
|
[[<VAR>function-body</VAR>]])],
|
|
[<VAR>action-if-true</VAR>],
|
|
[<VAR>action-if-false</VAR>])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
.</P><P>
|
|
|
|
This macro double quotes both <VAR>includes</VAR>
|
|
and <VAR>function-body</VAR>.</P><P>
|
|
|
|
Depending on the current language (Language Choice), create a
|
|
test program to see whether a function whose body consists of
|
|
<VAR>function-body</VAR> can be compiled and linked.
|
|
If the file compiles and links successfully, run shell commands
|
|
<VAR>action-if-found</VAR>, otherwise run
|
|
<VAR>action-if-not-found</VAR>.</P><P>
|
|
|
|
This macro double quotes both <VAR>includes</VAR>
|
|
and <VAR>function-body</VAR>.</P><P>
|
|
|
|
For C and C++, <VAR>includes</VAR> is any
|
|
<CODE>#include</CODE> statements needed by the code
|
|
in <VAR>function-body</VAR>
|
|
(<VAR>includes</VAR> is ignored if the currently
|
|
selected language is Fortran or Fortran 77). The compiler and
|
|
compilation flags are determined by the current language
|
|
(Language Choice), and in addition
|
|
<CODE>LDFLAGS</CODE> and
|
|
<CODE>LIBS</CODE> are used for linking.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TRY_LINK_FUNC">
|
|
<prototype>
|
|
<parameter content="function"/>
|
|
<parameter content="[action-if-found]"/>
|
|
<parameter content="@ [action-if-not-found]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro is equivalent to
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_LINK_IFELSE([AC_LANG_CALL([],
|
|
[<VAR>function</VAR>])],
|
|
[<VAR>action-if-found</VAR>],
|
|
[<VAR>action-if-not-found</VAR>])
|
|
</pre></td></tr></table> .
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TRY_RUN">
|
|
<prototype>
|
|
<parameter content="program"/>
|
|
<parameter content="[action-if-true]"/>
|
|
<parameter content="@ [action-if-false]"/>
|
|
<parameter content="[action-if-cross-compiling]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_RUN_IFELSE(
|
|
[AC_LANG_SOURCE([[<VAR>program</VAR>]])],
|
|
[<VAR>action-if-true</VAR>],
|
|
[<VAR>action-if-false</VAR>],
|
|
[<VAR>action-if-cross-compiling</VAR>])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_TYPE_SIGNAL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
signal.h If <TT>signal.h</TT> declares
|
|
<CODE>signal</CODE> as returning a pointer to a
|
|
function returning <CODE>void</CODE>, define
|
|
<CODE>RETSIGTYPE</CODE> to be
|
|
<CODE>void</CODE>; otherwise, define it to be
|
|
<CODE>int</CODE>. These days, it is portable to
|
|
assume C89, and that signal handlers return
|
|
<CODE>void</CODE>, without needing to use this macro
|
|
or <CODE>RETSIGTYPE</CODE>.</P><P>
|
|
|
|
When targetting older K&R C, it is possible to define signal
|
|
handlers as returning type <CODE>RETSIGTYPE</CODE>,
|
|
and omit a return statement:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> @group RETSIGTYPE hup_handler ()
|
|
<small>...</small> @ @end group
|
|
</pre></td></tr></table>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_UID_T">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_TYPE_UID_T</CODE>
|
|
(AC_TYPE_UID_T).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_UNISTD_H">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Same as <samp>AC_CHECK_HEADERS([unistd.h])</samp>
|
|
(AC_CHECK_HEADERS).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_USG">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Define <CODE>USG</CODE> if the BSD string
|
|
functions are defined in <TT>strings.h</TT>. You
|
|
should no longer depend upon <CODE>USG</CODE>, but
|
|
on <CODE>HAVE_STRING_H</CODE>; see Standard Symbols.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_UTIME_NULL">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_FUNC_UTIME_NULL</CODE>
|
|
(AC_FUNC_UTIME_NULL).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_VALIDATE_CACHED_SYSTEM_TUPLE">
|
|
<prototype>
|
|
<parameter content="[cmd]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If the cache file is inconsistent with the current host, target
|
|
and build system types, it used to execute
|
|
<VAR>cmd</VAR> or print a default error message.
|
|
This is now handled by default.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_VERBOSE">
|
|
<prototype>
|
|
<parameter content="result-description"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_MSG_RESULT</CODE>
|
|
(AC_MSG_RESULT).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_VFORK">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_FUNC_FORK</CODE>
|
|
(AC_FUNC_FORK).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_VPRINTF">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_FUNC_VPRINTF</CODE>
|
|
(AC_FUNC_VPRINTF).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_WAIT3">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was renamed <CODE>AC_FUNC_WAIT3</CODE>.
|
|
However, these days portable programs should use
|
|
<CODE>waitpid</CODE>, not
|
|
<CODE>wait3</CODE>, as
|
|
<CODE>wait3</CODE> has been removed from Posix.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_WARN">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_MSG_WARN</CODE> (AC_MSG_WARN).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_WITH">
|
|
<prototype>
|
|
<parameter content="package"/>
|
|
<parameter content="action-if-given"/>
|
|
<parameter content="@ [action-if-not-given]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This is an obsolete version of
|
|
<CODE>AC_ARG_WITH</CODE> that does not support
|
|
providing a help string (AC_ARG_WITH).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_WORDS_BIGENDIAN">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Replaced by <CODE>AC_C_BIGENDIAN</CODE>
|
|
(AC_C_BIGENDIAN).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_XENIX_DIR">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro used to add <samp>-lx</samp> to output
|
|
variable <CODE>LIBS</CODE> if on Xenix. Also, if
|
|
<TT>dirent.h</TT> is being checked for, added
|
|
<samp>-ldir</samp> to <CODE>LIBS</CODE>.
|
|
Now it is merely an alias of
|
|
<CODE>AC_HEADER_DIRENT</CODE> instead, plus some
|
|
code to detect whether running XENIX on which you should not
|
|
depend:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AC_MSG_CHECKING([for Xenix])
|
|
AC_EGREP_CPP([yes], [#if defined M_XENIX && !defined
|
|
M_UNIX yes #endif], [AC_MSG_RESULT([yes]);
|
|
XENIX=yes], [AC_MSG_RESULT([no]); XENIX=])
|
|
</pre></td></tr></table> Don't use this
|
|
macro, the dignified means to check the nature of the host is
|
|
using <CODE>AC_CANONICAL_HOST</CODE>
|
|
(Canonicalizing).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_YYTEXT_POINTER">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro was renamed <CODE>AC_DECL_YYTEXT</CODE>,
|
|
which in turn was integrated into
|
|
<CODE>AC_PROG_LEX</CODE> (AC_PROG_LEX).
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_INIT">
|
|
<prototype>
|
|
<parameter content="[name]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Initialize Autotest. Giving a <VAR>name</VAR> to
|
|
the test suite is encouraged if your package includes several
|
|
test suites. Before this macro is called,
|
|
<CODE>AT_PACKAGE_STRING</CODE> and
|
|
<CODE>AT_PACKAGE_BUGREPORT</CODE> must be defined,
|
|
which are used to display information about the testsuite to the
|
|
user. Typically, these macros are provided by a file
|
|
<TT>package.m4</TT> built by
|
|
<CODE>make</CODE> (Making testsuite Scripts), in
|
|
order to inherit the package name, version, and bug reporting
|
|
address from <TT>configure.ac</TT>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_COPYRIGHT">
|
|
<prototype>
|
|
<parameter content="copyright-notice"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Notice State that, in addition to the Free Software
|
|
Foundation's copyright on the Autotest macros, parts of your
|
|
test suite are covered by
|
|
<VAR>copyright-notice</VAR>.</P><P>
|
|
|
|
The <VAR>copyright-notice</VAR> shows up in both the
|
|
head of <CODE>testsuite</CODE> and in
|
|
<samp>testsuite --version</samp>.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_ARG_OPTION">
|
|
<prototype>
|
|
<parameter content="options"/>
|
|
<parameter content="help-text"/>
|
|
<parameter content="@ [action-if-given]"/>
|
|
<parameter content="[action-if-not-given]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Accept options from the space-separated list
|
|
<VAR>options</VAR>, a list that has leading dashes
|
|
removed from the options. Long options will be prefixed with
|
|
<samp>--</samp>, single-character options with
|
|
<samp>-</samp>. The first word in this list is the
|
|
primary <VAR>option</VAR>, any others are assumed to
|
|
be short-hand aliases. The variable associated with it is
|
|
<CODE>at_arg_<VAR>option</VAR></CODE>,
|
|
with any dashes in <VAR>option</VAR> replaced with
|
|
underscores.</P><P>
|
|
|
|
If the user passes
|
|
<samp>--<VAR>option</VAR></samp> to the
|
|
<CODE>testsuite</CODE>, the variable will be set to
|
|
<samp>:</samp>. If the user does not pass the
|
|
option, or passes
|
|
<samp>--no-<VAR>option</VAR></samp>,
|
|
then the variable will be set to <samp>false</samp>.</P><P>
|
|
|
|
<VAR>action-if-given</VAR> is run each time the
|
|
option is encountered; here, the variable
|
|
<CODE>at_optarg</CODE> will be set to
|
|
<samp>:</samp> or <samp>false</samp> as
|
|
appropriate. <CODE>at_optarg</CODE> is actually
|
|
just a copy of
|
|
<CODE>at_arg_<VAR>option</VAR></CODE>.</P><P>
|
|
|
|
<VAR>action-if-not-given</VAR> will be run once
|
|
after option parsing is complete and if no option from
|
|
<VAR>options</VAR> was used.</P><P>
|
|
|
|
<VAR>help-text</VAR> is added to the end of the list
|
|
of options shown in <CODE>testsuite --help</CODE>
|
|
(AS_HELP_STRING).</P><P>
|
|
|
|
It it recommended that you use a package-specific prefix to
|
|
<VAR>options</VAR> names in order to avoid clashes
|
|
with future Autotest built-in options.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_ARG_OPTION_ARG">
|
|
<prototype>
|
|
<parameter content="options"/>
|
|
<parameter content="help-text"/>
|
|
<parameter content="@ [action-if-given]"/>
|
|
<parameter content="[action-if-not-given]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Accept options with arguments from the space-separated list
|
|
<VAR>options</VAR>, a list that has leading dashes
|
|
removed from the options. Long options will be prefixed with
|
|
<samp>--</samp>, single-character options with
|
|
<samp>-</samp>. The first word in this list is the
|
|
primary <VAR>option</VAR>, any others are assumed to
|
|
be short-hand aliases. The variable associated with it is
|
|
<CODE>at_arg_<VAR>option</VAR></CODE>,
|
|
with any dashes in <VAR>option</VAR> replaced with
|
|
underscores.</P><P>
|
|
|
|
If the user passes
|
|
<samp>--<VAR>option</VAR>=<VAR>arg</VAR></samp>
|
|
or <samp>--<VAR>option</VAR>
|
|
<VAR>arg</VAR></samp> to the
|
|
<CODE>testsuite</CODE>, the variable will be set to
|
|
<samp><VAR>arg</VAR></samp>.</P><P>
|
|
|
|
<VAR>action-if-given</VAR> is run each time the
|
|
option is encountered; here, the variable
|
|
<CODE>at_optarg</CODE> will be set to
|
|
<samp><VAR>arg</VAR></samp>.
|
|
<CODE>at_optarg</CODE> is actually just a copy of
|
|
<CODE>at_arg_<VAR>option</VAR></CODE>.</P><P>
|
|
|
|
<VAR>action-if-not-given</VAR> will be run once
|
|
after option parsing is complete and if no option from
|
|
<VAR>options</VAR> was used.</P><P>
|
|
|
|
<VAR>help-text</VAR> is added to the end of the list
|
|
of options shown in <CODE>testsuite --help</CODE>
|
|
(AS_HELP_STRING).</P><P>
|
|
|
|
It it recommended that you use a package-specific prefix to
|
|
<VAR>options</VAR> names in order to avoid clashes
|
|
with future Autotest built-in options.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_COLOR_TESTS">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
Enable colored test results by default when the output is
|
|
connected to a terminal.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_TESTED">
|
|
<prototype>
|
|
<parameter content="executables"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Log the file name and answer to
|
|
<samp>--version</samp> of each program in
|
|
space-separated list <VAR>executables</VAR>.
|
|
Several invocations register new executables, in other words,
|
|
don't fear registering one program several times.</P><P>
|
|
|
|
Autotest test suites rely on PATH to find the tested program.
|
|
This avoids the need to generate absolute names of the various
|
|
tools, and makes it possible to test installed programs.
|
|
Therefore, knowing which programs are being exercised is crucial
|
|
to understanding problems in the test suite itself, or its
|
|
occasional misuses. It is a good idea to also subscribe foreign
|
|
programs you depend upon, to avoid incompatible diagnostics.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_BANNER">
|
|
<prototype>
|
|
<parameter content="test-category-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro identifies the start of a category of related test
|
|
groups. When the resulting <TT>testsuite</TT> is
|
|
invoked with more than one test group to run, its output will
|
|
include a banner containing
|
|
<VAR>test-category-name</VAR> prior to any tests run
|
|
from that category. The banner should be no more than about 40
|
|
or 50 characters. A blank banner indicates uncategorized tests;
|
|
an empty line will be inserted after tests from an earlier
|
|
category, effectively ending that category.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_SETUP">
|
|
<prototype>
|
|
<parameter content="test-group-name"/>
|
|
</prototype>
|
|
<synopsis>
|
|
This macro starts a group of related tests, all to be executed
|
|
in the same subshell. It accepts a single argument, which holds
|
|
a few words (no more than about 30 or 40 characters) quickly
|
|
describing the purpose of the test group being started.
|
|
<VAR>test-group-name</VAR> must not expand to
|
|
unbalanced quotes, although quadrigraphs can be used.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_KEYWORDS">
|
|
<prototype>
|
|
<parameter content="keywords"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Associate the space-separated list of
|
|
<VAR>keywords</VAR> to the enclosing test group.
|
|
This makes it possible to run ``slices'' of the test suite. For
|
|
instance, if some of your test groups exercise some
|
|
<samp>foo</samp> feature, then using
|
|
<samp>AT_KEYWORDS(foo)</samp> lets you run
|
|
<samp>./testsuite -k foo</samp> to run exclusively
|
|
these test groups. The <VAR>test-group-name</VAR>
|
|
of the test group is automatically recorded to
|
|
<CODE>AT_KEYWORDS</CODE>.</P><P>
|
|
|
|
Several invocations within a test group accumulate new keywords.
|
|
In other words, don't fear registering the same keyword several
|
|
times in a test group.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_CAPTURE_FILE">
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
</prototype>
|
|
<synopsis>
|
|
If the current test group fails, log the contents of
|
|
<VAR>file</VAR>. Several identical calls within one
|
|
test group have no additional effect.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_FAIL_IF">
|
|
<prototype>
|
|
<parameter content="shell-condition"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Make the test group fail and skip the rest of its execution, if
|
|
<VAR>shell-condition</VAR> is true.
|
|
<VAR>shell-condition</VAR> is a shell expression
|
|
such as a <CODE>test</CODE> command. Tests before
|
|
<CODE>AT_FAIL_IF</CODE> will be executed and may
|
|
still cause the test group to be skipped. You can instantiate
|
|
this macro many times from within the same test group.</P><P>
|
|
|
|
You should use this macro only for very simple failure
|
|
conditions. If the <VAR>shell-condition</VAR> could
|
|
emit any kind of output you should instead use
|
|
<CODE>AT_CHECK</CODE> like
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AT_CHECK([if
|
|
<VAR>shell-condition</VAR>; then exit 99; fi])
|
|
</pre></td></tr></table> so that such
|
|
output is properly recorded in the
|
|
<TT>testsuite.log</TT> file.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_SKIP_IF">
|
|
<prototype>
|
|
<parameter content="shell-condition"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine whether the test should be skipped because it
|
|
requires features that are unsupported on the machine under
|
|
test. <VAR>shell-condition</VAR> is a shell
|
|
expression such as a <CODE>test</CODE> command.
|
|
Tests before <CODE>AT_SKIP_IF</CODE> will be
|
|
executed and may still cause the test group to fail. You can
|
|
instantiate this macro many times from within the same test
|
|
group.</P><P>
|
|
|
|
You should use this macro only for very simple skip conditions.
|
|
If the <VAR>shell-condition</VAR> could emit any
|
|
kind of output you should instead use
|
|
<CODE>AT_CHECK</CODE> like
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AT_CHECK([if
|
|
<VAR>shell-condition</VAR>; then exit 77; fi])
|
|
</pre></td></tr></table> so that such
|
|
output is properly recorded in the
|
|
<TT>testsuite.log</TT> file.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_XFAIL_IF">
|
|
<prototype>
|
|
<parameter content="shell-condition"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Determine whether the test is expected to fail because it is a
|
|
known bug (for unsupported features, you should skip the test).
|
|
<VAR>shell-condition</VAR> is a shell expression
|
|
such as a <CODE>test</CODE> command; you can
|
|
instantiate this macro many times from within the same test
|
|
group, and one of the conditions is enough to turn the test into
|
|
an expected failure.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_CLEANUP">
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
End the current test group.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_DATA">
|
|
<prototype>
|
|
<parameter content="file"/>
|
|
<parameter content="contents"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Initialize an input data <VAR>file</VAR> with given
|
|
<VAR>contents</VAR>. Of course, the
|
|
<VAR>contents</VAR> have to be properly quoted
|
|
between square brackets to protect against included commas or
|
|
spurious M4 expansion. <VAR>contents</VAR> must be
|
|
empty or end with a newline. <VAR>file</VAR> must be
|
|
a single shell word that expands into a single file name.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_CHECK">
|
|
<prototype>
|
|
<parameter content="commands"/>
|
|
<parameter content="[status= 0]"/>
|
|
<parameter content="[stdout]"/>
|
|
<parameter content="@ [stderr]"/>
|
|
<parameter content="[run-if-fail]"/>
|
|
<parameter content="[run-if-pass]"/>
|
|
</prototype>
|
|
<prototype>
|
|
</prototype>
|
|
<synopsis>
|
|
stderr, run-if-fail, run-if-pass) Execute a test by
|
|
performing given shell <VAR>commands</VAR> in a
|
|
subshell. <VAR>commands</VAR> is output as-is, so
|
|
shell expansions are honored. These commands should normally
|
|
exit with <VAR>status</VAR>, while producing
|
|
expected <VAR>stdout</VAR> and
|
|
<VAR>stderr</VAR> contents. If
|
|
<VAR>commands</VAR> exit with unexpected status 77,
|
|
then the rest of the test group is skipped. If
|
|
<VAR>commands</VAR> exit with unexpected status 99,
|
|
then the test group is immediately failed. Otherwise, if this
|
|
test fails, run shell commands
|
|
<VAR>run-if-fail</VAR> or, if this test passes, run
|
|
shell commands <VAR>run-if-pass</VAR>, both inside
|
|
the current shell execution environment. At the beginning of
|
|
<VAR>run-if-fail</VAR> and
|
|
<VAR>run-if-pass</VAR>, the status of
|
|
<VAR>commands</VAR> is available in the
|
|
<CODE>at_status</CODE> shell variable.</P><P>
|
|
|
|
This macro must be invoked in between
|
|
<CODE>AT_SETUP</CODE> and
|
|
<CODE>AT_CLEANUP</CODE>.</P><P>
|
|
|
|
If <VAR>status</VAR> is the literal
|
|
<samp>ignore</samp>, then the corresponding exit
|
|
status is not checked, except for the special cases of 77 (skip)
|
|
and 99 (hard failure). The existence of hard failures allows
|
|
one to mark a test as an expected failure with
|
|
<CODE>AT_XFAIL_IF</CODE> because a feature has not
|
|
yet been implemented, but to still distinguish between
|
|
gracefully handling the missing feature and dumping core. A
|
|
hard failure also inhibits post-test actions in
|
|
<VAR>run-if-fail</VAR>.</P><P>
|
|
|
|
If the value of the <VAR>stdout</VAR> or
|
|
<VAR>stderr</VAR> parameter is one of the literals
|
|
in the following table, then the test treats the output
|
|
according to the rules of that literal. Otherwise, the value of
|
|
the parameter is treated as text that must exactly match the
|
|
output given by <VAR>commands</VAR> on standard
|
|
output and standard error (including an empty parameter for no
|
|
output); any differences are captured in the testsuite log and
|
|
the test is failed (unless an unexpected exit status of 77
|
|
skipped the test instead). The difference between
|
|
<CODE>AT_CHECK</CODE> and
|
|
<CODE>AT_CHECK_UNQUOTED</CODE> is that only the
|
|
latter performs shell variable expansion
|
|
(<samp>$</samp>), command substitution
|
|
(<samp>`</samp>), and backslash escaping
|
|
(<samp>\</samp>) on comparison text given in the
|
|
<VAR>stdout</VAR> and <VAR>stderr</VAR>
|
|
arguments; if the text includes a trailing newline, this would
|
|
be the same as if it were specified via an unquoted
|
|
here-document. (However, there is no difference in the
|
|
interpretation of <VAR>commands</VAR>).</P><P>
|
|
|
|
<DL> <DT>'<SAMP>ignore</SAMP>'
|
|
<DD> The content of the output is ignored, but still
|
|
captured in the test group log (if the testsuite is run with
|
|
option <samp>-v</samp>, the test group log is
|
|
displayed as the test is run; if the test group later fails, the
|
|
test group log is also copied into the overall testsuite log).
|
|
This action is valid for both <VAR>stdout</VAR> and
|
|
<VAR>stderr</VAR>.</P><P>
|
|
|
|
<DT>'<SAMP>ignore-nolog</SAMP>' <DD> The
|
|
content of the output is ignored, and nothing is captured in the
|
|
log files. If <VAR>commands</VAR> are likely to
|
|
produce binary output (including long lines) or large amounts of
|
|
output, then logging the output can make it harder to locate
|
|
details related to subsequent tests within the group, and could
|
|
potentially corrupt terminal display of a user running
|
|
<CODE>testsuite -v</CODE>.</P><P>
|
|
|
|
<DT>'<SAMP>stdout</SAMP>' <DD> For the
|
|
<VAR>stdout</VAR> parameter, capture the content of
|
|
standard output to both the file <TT>stdout</TT> and
|
|
the test group log. Subsequent commands in the test group can
|
|
then post-process the file. This action is often used when it
|
|
is desired to use <CODE>grep</CODE> to look for a
|
|
substring in the output, or when the output must be
|
|
post-processed to normalize error messages into a common form.</P><P>
|
|
|
|
<DT>'<SAMP>stderr</SAMP>' <DD> Like
|
|
<samp>stdout</samp>, except that it only works for
|
|
the <VAR>stderr</VAR> parameter, and the standard
|
|
error capture file will be named <TT>stderr</TT>.</P><P>
|
|
|
|
<DT>'<SAMP>stdout-nolog</SAMP>' <DD>
|
|
<DT>'<SAMP>x stderr-nolog</SAMP>' <DD>
|
|
Like <samp>stdout</samp> or
|
|
<samp>stderr</samp>, except that the captured output
|
|
is not duplicated into the test group log. This action is
|
|
particularly useful for an intermediate check that produces
|
|
large amounts of data, which will be followed by another check
|
|
that filters down to the relevant data, as it makes it easier to
|
|
locate details in the log.</P><P>
|
|
|
|
<DT>'<SAMP>expout</SAMP>' <DD> For the
|
|
<VAR>stdout</VAR> parameter, compare standard output
|
|
contents with the previously created file
|
|
<TT>expout</TT>, and list any differences in the
|
|
testsuite log.</P><P>
|
|
|
|
<DT>'<SAMP>experr</SAMP>' <DD> Like
|
|
<samp>expout</samp>, except that it only works for
|
|
the <VAR>stderr</VAR> parameter, and the standard
|
|
error contents are compared with <TT>experr</TT>.
|
|
</DL>
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AT_CHECK_EUNIT">
|
|
<prototype>
|
|
<parameter content="module"/>
|
|
<parameter content="test-spec"/>
|
|
<parameter content="[erlflags]"/>
|
|
<parameter content="@ [run-if-fail]"/>
|
|
<parameter content="[run-if-pass]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
Initialize and execute an Erlang module named
|
|
<VAR>module</VAR> that performs tests following the
|
|
<VAR>test-spec</VAR> EUnit test specification.
|
|
<VAR>test-spec</VAR> must be a valid EUnit test
|
|
specification, as defined in the
|
|
http://@/erlang.org/@/doc/@/apps/@/eunit/@/index.html, EUnit
|
|
Reference Manual. <VAR>erlflags</VAR> are optional
|
|
command-line options passed to the Erlang interpreter to execute
|
|
the test Erlang module. Typically,
|
|
<VAR>erlflags</VAR> defines at least the paths to
|
|
directories containing the compiled Erlang modules under test,
|
|
as <samp>-pa path1 path2 ...</samp>.</P><P>
|
|
|
|
For example, the unit tests associated with Erlang module
|
|
<samp>testme</samp>, which compiled code is in
|
|
subdirectory <TT>src</TT>, can be performed with:</P><P>
|
|
|
|
<TABLE><tr><td>&nbsp;</td><td
|
|
class=example><pre> AT_CHECK_EUNIT([testme_testsuite],
|
|
[module, testme@], [-pa
|
|
"$abs_top_builddir@/src"])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This macro must be invoked in between
|
|
<CODE>AT_SETUP</CODE> and
|
|
<CODE>AT_CLEANUP</CODE>.</P><P>
|
|
|
|
Variables <CODE>ERL</CODE>,
|
|
<CODE>ERLC</CODE>, and (optionally)
|
|
<CODE>ERLCFLAGS</CODE> must be defined as the path
|
|
of the Erlang interpreter, the path of the Erlang compiler, and
|
|
the command-line flags to pass to the compiler, respectively.
|
|
Those variables should be configured in
|
|
<TT>configure.ac</TT> using the
|
|
<CODE>AC_ERLANG_PATH_ERL</CODE> and
|
|
<CODE>AC_ERLANG_PATH_ERLC</CODE> macros, and the
|
|
configured values of those variables are automatically defined
|
|
in the testsuite. If <CODE>ERL</CODE> or
|
|
<CODE>ERLC</CODE> is not defined, the test group is
|
|
skipped.</P><P>
|
|
|
|
If the EUnit library cannot be found, i.e. if module
|
|
<CODE>eunit</CODE> cannot be loaded, the test group
|
|
is skipped. Otherwise, if <VAR>test-spec</VAR> is
|
|
an invalid EUnit test specification, the test group fails.
|
|
Otherwise, if the EUnit test passes, shell commands
|
|
<VAR>run-if-pass</VAR> are executed or, if the EUnit
|
|
test fails, shell commands <VAR>run-if-fail</VAR>
|
|
are executed and the test group fails.</P><P>
|
|
|
|
Only the generated test Erlang module is automatically compiled
|
|
and executed. If <VAR>test-spec</VAR> involves
|
|
testing other Erlang modules, e.g. module
|
|
<samp>testme</samp> in the example above, those
|
|
modules must be already compiled.</P><P>
|
|
|
|
If the testsuite is run in verbose mode, with option
|
|
<samp>--verbose</samp>, EUnit is also run in verbose
|
|
mode to output more details about individual unit tests.
|
|
</synopsis>
|
|
</macro>
|
|
<macro id="AC_CONFIG_TESTDIR">
|
|
<prototype>
|
|
<parameter content="directory"/>
|
|
<parameter content="[test-path= directory]"/>
|
|
</prototype>
|
|
<synopsis>
|
|
An Autotest test suite is to be configured in
|
|
<VAR>directory</VAR>. This macro causes
|
|
<TT><VAR>directory</VAR>/atconfig</TT>
|
|
to be created by <CODE>config.status</CODE> and sets
|
|
the default <CODE>AUTOTEST_PATH</CODE> to
|
|
<VAR>test-path</VAR> (testsuite Invocation).
|
|
</synopsis>
|
|
</macro>
|
|
</macros>
|