*** /dev/null Fri May 3 06:52:10 2024
--- - Fri May 3 06:52:58 2024
***************
*** 0 ****
--- 1,17513 ----
+ <HTML>
+ <HEAD>
+ <!-- Created by texi2html 1.56k from autoconf.texi on 10 July 2002 -->
+
+ <TITLE>Autoconf</TITLE>
+ </HEAD>
+ <BODY>
+ <H1>Autoconf</H1>
+ <H2>Creating Automatic Configuration Scripts</H2>
+ <H2>Edition 2.53, for Autoconf version 2.53</H2>
+ <H2>8 March 2002</H2>
+ <ADDRESS>David MacKenzie</ADDRESS>
+ <ADDRESS>Ben Elliston</ADDRESS>
+ <ADDRESS>Akim Demaille</ADDRESS>
+ <P>
+ <P><HR><P>
+
+
+ <H1><A NAME="SEC1" HREF="autoconf_toc.html#TOC1">Introduction</A></H1>
+
+
+ <PRE>
+ A physicist, an engineer, and a computer scientist were discussing the
+ nature of God. ``Surely a Physicist,'' said the physicist, ``because
+ early in the Creation, God made Light; and you know, Maxwell's
+ equations, the dual nature of electromagnetic waves, the relativistic
+ consequences...'' ``An Engineer!,'' said the engineer, ``because
+ before making Light, God split the Chaos into Land and Water; it takes a
+ hell of an engineer to handle that big amount of mud, and orderly
+ separation of solids from liquids...'' The computer scientist
+ shouted: ``And the Chaos, where do you think it was coming from, hmm?''
+
+ ---Anonymous
+ </PRE>
+
+ <P>
+ Autoconf is a tool for producing shell scripts that automatically
+ configure software source code packages to adapt to many kinds of
+ UNIX-like systems. The configuration scripts produced by Autoconf
+ are independent of Autoconf when they are run, so their users do not
+ need to have Autoconf.
+
+
+ <P>
+ The configuration scripts produced by Autoconf require no manual user
+ intervention when run; they do not normally even need an argument
+ specifying the system type. Instead, they individually test for the
+ presence of each feature that the software package they are for might need.
+ (Before each check, they print a one-line message stating what they are
+ checking for, so the user doesn't get too bored while waiting for the
+ script to finish.) As a result, they deal well with systems that are
+ hybrids or customized from the more common UNIX variants. There is
+ no need to maintain files that list the features supported by each
+ release of each variant of UNIX.
+
+
+ <P>
+ For each software package that Autoconf is used with, it creates a
+ configuration script from a template file that lists the system features
+ that the package needs or can use. After the shell code to recognize
+ and respond to a system feature has been written, Autoconf allows it to
+ be shared by many software packages that can use (or need) that feature.
+ If it later turns out that the shell code needs adjustment for some
+ reason, it needs to be changed in only one place; all of the
+ configuration scripts can be regenerated automatically to take advantage
+ of the updated code.
+
+
+ <P>
+ The Metaconfig package is similar in purpose to Autoconf, but the
+ scripts it produces require manual user intervention, which is quite
+ inconvenient when configuring large source trees. Unlike Metaconfig
+ scripts, Autoconf scripts can support cross-compiling, if some care is
+ taken in writing them.
+
+
+ <P>
+ Autoconf does not solve all problems related to making portable software
+ packages--for a more complete solution, it should be used in concert
+ with other GNU build tools like Automake and Libtool. These other tools
+ take on jobs like the creation of a portable, recursive <TT>`Makefile'</TT>
+ with all of the standard targets, linking of shared libraries, and so
+ on. See section <A HREF="autoconf.html#SEC2">The GNU build system</A>, for more information.
+
+
+ <P>
+ Autoconf imposes some restrictions on the names of macros used with
+ <CODE>#if</CODE> in C programs (see section <A HREF="autoconf.html#SEC186">Preprocessor Symbol Index</A>).
+
+
+ <P>
+ Autoconf requires GNU M4 in order to generate the scripts. It uses
+ features that some UNIX versions of M4, including GNU M4 1.3,
+ do not have. You must use version 1.4 or later of GNU M4.
+
+
+ <P>
+ See section <A HREF="autoconf.html#SEC151">Upgrading From Version 1</A>, for information about upgrading from version 1.
+ See section <A HREF="autoconf.html#SEC174">History of Autoconf</A>, for the story of Autoconf's development.
+ See section <A HREF="autoconf.html#SEC169">Questions About Autoconf</A>, for answers to some common questions about Autoconf.
+
+
+ <P>
+ See the @href{http://www.gnu.org/software/autoconf/autoconf.html,
+ Autoconf web page} for up-to-date information, details on the mailing
+ lists, pointers to a list of known bugs, etc.
+
+
+ <P>
+ Mail suggestions to <A HREF="mailto:autoconf@gnu.org">the Autoconf mailing
+ list</A>.
+
+
+ <P>
+ Bug reports should be preferably submitted to the
+ @href{http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=autoconf,
+ Autoconf Gnats database}, or sent to <A HREF="mailto:bug-autoconf@gnu.org">the
+ Autoconf Bugs mailing list</A>. If possible, first check that your bug is
+ not already solved in current development versions, and that it has not
+ been reported yet. Be sure to include all the needed information and a
+ short <TT>`configure.ac'</TT> that demonstrates the problem.
+
+
+ <P>
+ Autoconf's development tree is accessible via CVS; see the Autoconf
+ web page for details. There is also a
+ @href{http://subversions.gnu.org/cgi-bin/cvsweb/autoconf/, CVSweb
+ interface to the Autoconf development tree}. Patches relative to the
+ current CVS version can be sent for review to the
+ <A HREF="mailto:autoconf-patches@gnu.org">Autoconf Patches mailing list</A>.
+
+
+ <P>
+ Because of its mission, Autoconf includes only a set of often-used
+ macros that have already demonstrated their usefulness. Nevertheless,
+ if you wish to share your macros, or find existing ones, see the
+ @href{http://www.gnu.org/software/ac-archive/, Autoconf Macro
+ Archive}, which is kindly run by <A HREF="mailto:simons@computer.org">Peter Simons</A>.
+
+
+
+
+ <H1><A NAME="SEC2" HREF="autoconf_toc.html#TOC2">The GNU build system</A></H1>
+
+ <P>
+ Autoconf solves an important problem--reliable discovery of
+ system-specific build and runtime information--but this is only one
+ piece of the puzzle for the development of portable software. To this
+ end, the GNU project has developed a suite of integrated utilities to
+ finish the job Autoconf started: the GNU build system, whose most
+ important components are Autoconf, Automake, and Libtool. In this
+ chapter, we introduce you to those tools, point you to sources of more
+ information, and try to convince you to use the entire GNU build system
+ for your software.
+
+
+
+
+ <H2><A NAME="SEC3" HREF="autoconf_toc.html#TOC3">Automake</A></H2>
+
+ <P>
+ The ubiquity of <CODE>make</CODE> means that a <CODE>Makefile</CODE> is almost the
+ only viable way to distribute automatic build rules for software, but
+ one quickly runs into <CODE>make</CODE>'s numerous limitations. Its lack of
+ support for automatic dependency tracking, recursive builds in
+ subdirectories, reliable timestamps (e.g. for network filesystems), and
+ so on, mean that developers must painfully (and often incorrectly)
+ reinvent the wheel for each project. Portability is non-trivial, thanks
+ to the quirks of <CODE>make</CODE> on many systems. On top of all this is the
+ manual labor required to implement the many standard targets that users
+ have come to expect (<CODE>make install</CODE>, <CODE>make distclean</CODE>,
+ <CODE>make uninstall</CODE>, etc.). Since you are, of course, using Autoconf,
+ you also have to insert repetitive code in your <CODE>Makefile.in</CODE> to
+ recognize <CODE>@CC@</CODE>, <CODE>@CFLAGS@</CODE>, and other substitutions
+ provided by @command{configure}. Into this mess steps <EM>Automake</EM>.
+ <A NAME="IDX1"></A>
+
+
+ <P>
+ Automake allows you to specify your build needs in a <CODE>Makefile.am</CODE>
+ file with a vastly simpler and more powerful syntax than that of a plain
+ <CODE>Makefile</CODE>, and then generates a portable <CODE>Makefile.in</CODE> for
+ use with Autoconf. For example, the <CODE>Makefile.am</CODE> to build and
+ install a simple "Hello world" program might look like:
+
+
+
+ <PRE>
+ bin_PROGRAMS = hello
+ hello_SOURCES = hello.c
+ </PRE>
+
+ <P>
+ The resulting <CODE>Makefile.in</CODE> (~400 lines) automatically supports all
+ the standard targets, the substitutions provided by Autoconf, automatic
+ dependency tracking, <CODE>VPATH</CODE> building, and so on. <CODE>make</CODE> will
+ build the <CODE>hello</CODE> program, and <CODE>make install</CODE> will install it
+ in <TT>`/usr/local/bin'</TT> (or whatever prefix was given to
+ @command{configure}, if not <TT>`/usr/local'</TT>).
+
+
+ <P>
+ Automake may require that additional tools be present on the
+ <EM>developer's</EM> machine. For example, the <CODE>Makefile.in</CODE> that
+ the developer works with may not be portable (e.g. it might use special
+ features of your compiler to automatically generate dependency
+ information). Running <CODE>make dist</CODE>, however, produces a
+ <TT>`hello-1.0.tar.gz'</TT> package (or whatever the program/version is)
+ with a <CODE>Makefile.in</CODE> that will work on any system.
+
+
+ <P>
+ The benefits of Automake increase for larger packages (especially ones
+ with subdirectories), but even for small programs the added convenience
+ and portability can be substantial. And that's not all...
+
+
+
+
+ <H2><A NAME="SEC4" HREF="autoconf_toc.html#TOC4">Libtool</A></H2>
+
+ <P>
+ Very often, one wants to build not only programs, but libraries, so that
+ other programs can benefit from the fruits of your labor. Ideally, one
+ would like to produce <EM>shared</EM> (dynamically-linked) libraries,
+ which can be used by multiple programs without duplication on disk or in
+ memory and can be updated independently of the linked programs.
+ Producing shared libraries portably, however, is the stuff of
+ nightmares--each system has its own incompatible tools, compiler flags,
+ and magic incantations. Fortunately, GNU provides a solution:
+ <EM>Libtool</EM>.
+ <A NAME="IDX2"></A>
+
+
+ <P>
+ Libtool handles all the requirements of building shared libraries for
+ you, and at this time seems to be the <EM>only</EM> way to do so with any
+ portability. It also handles many other headaches, such as: the
+ interaction of <CODE>Makefile</CODE> rules with the variable suffixes of
+ shared libraries, linking reliably to shared libraries before they are
+ installed by the superuser, and supplying a consistent versioning system
+ (so that different versions of a library can be installed or upgraded
+ without breaking binary compatibility). Although Libtool, like
+ Autoconf, can be used on its own, it is most simply utilized in
+ conjunction with Automake--there, Libtool is used automatically
+ whenever shared libraries are needed, and you need not know its syntax.
+
+
+
+
+ <H2><A NAME="SEC5" HREF="autoconf_toc.html#TOC5">Pointers</A></H2>
+
+ <P>
+ Developers who are used to the simplicity of <CODE>make</CODE> for small
+ projects on a single system might be daunted at the prospect of learning
+ to use Automake and Autoconf. As your software is distributed to more
+ and more users, however, you will otherwise quickly find yourself
+ putting lots of effort into reinventing the services that the GNU build
+ tools provide, and making the same mistakes that they once made and
+ overcame. (Besides, since you're already learning Autoconf, Automake
+ will be a piece of cake.)
+
+
+ <P>
+ There are a number of places that you can go to for more information on
+ the GNU build tools.
+
+
+
+ <UL>
+
+ <LI>Web
+
+ The home pages for
+ @href{http://www.gnu.org/software/autoconf/,Autoconf},
+ @href{http://www.gnu.org/software/automake/,Automake}, and
+ @href{http://www.gnu.org/software/libtool/,Libtool}.
+
+ <LI>Automake Manual
+
+ See section `Automake' in <CITE>GNU Automake</CITE>, for more
+ information on Automake.
+
+ <LI>Books
+
+ The book <CITE>GNU Autoconf, Automake and Libtool</CITE><A NAME="DOCF1" HREF="autoconf_foot.html#FOOT1">(1)</A>
+ describes the complete GNU build environment. You can also find the
+ entire book on-line at @href{http://sources.redhat.com/autobook/,"The
+ Goat Book" home page}.
+
+ <LI>Tutorials and Examples
+
+ The @href{http://sources.redhat.com/autoconf/,Autoconf Developer Page}
+ maintains links to a number of Autoconf/Automake tutorials online, and
+ also links to the @href{http://www.gnu.org/software/ac-archive/,
+ Autoconf Macro Archive}.
+
+ </UL>
+
+
+
+ <H1><A NAME="SEC6" HREF="autoconf_toc.html#TOC6">Making @command{configure} Scripts</A></H1>
+ <P>
+ <A NAME="IDX3"></A>
+ <A NAME="IDX4"></A>
+
+
+ <P>
+ The configuration scripts that Autoconf produces are by convention
+ called @command{configure}. When run, @command{configure} creates several
+ files, replacing configuration parameters in them with appropriate
+ values. The files that @command{configure} creates are:
+
+
+
+ <UL>
+ <LI>
+
+ one or more <TT>`Makefile'</TT> files, one in each subdirectory of the
+ package (see section <A HREF="autoconf.html#SEC22">Substitutions in Makefiles</A>);
+
+ <LI>
+
+ optionally, a C header file, the name of which is configurable,
+ containing <CODE>#define</CODE> directives (see section <A HREF="autoconf.html#SEC27">Configuration Header Files</A>);
+
+ <LI>
+
+ a shell script called <TT>`config.status'</TT> that, when run, will recreate
+ the files listed above (see section <A HREF="autoconf.html#SEC145">Recreating a Configuration</A>);
+
+ <LI>
+
+ an optional shell script normally called <TT>`config.cache'</TT>
+ (created when using <SAMP>`configure --config-cache'</SAMP>) that
+ saves the results of running many of the tests (see section <A HREF="autoconf.html#SEC84">Cache Files</A>);
+
+ <LI>
+
+ a file called <TT>`config.log'</TT> containing any messages produced by
+ compilers, to help debugging if @command{configure} makes a mistake.
+ </UL>
+
+ <P>
+ <A NAME="IDX5"></A>
+ <A NAME="IDX6"></A>
+ To create a @command{configure} script with Autoconf, you need to write an
+ Autoconf input file <TT>`configure.ac'</TT> (or <TT>`configure.in'</TT>) and run
+ @command{autoconf} on it. If you write your own feature tests to
+ supplement those that come with Autoconf, you might also write files
+ called <TT>`aclocal.m4'</TT> and <TT>`acsite.m4'</TT>. If you use a C header
+ file to contain <CODE>#define</CODE> directives, you might also run
+ @command{autoheader}, and you will distribute the generated file
+ <TT>`config.h.in'</TT> with the package.
+
+
+ <P>
+ Here is a diagram showing how the files that can be used in
+ configuration are produced. Programs that are executed are suffixed by
+ <SAMP>`*'</SAMP>. Optional files are enclosed in square brackets (<SAMP>`[]'</SAMP>).
+ @command{autoconf} and @command{autoheader} also read the installed Autoconf
+ macro files (by reading <TT>`autoconf.m4'</TT>).
+
+
+ <P>
+ Files used in preparing a software package for distribution:
+
+ <PRE>
+ your source files --> [autoscan*] --> [configure.scan] --> configure.ac
+
+ configure.ac --.
+ | .------> autoconf* -----> configure
+ [aclocal.m4] --+---+
+ | `-----> [autoheader*] --> [config.h.in]
+ [acsite.m4] ---'
+
+ Makefile.in -------------------------------> Makefile.in
+ </PRE>
+
+ <P>
+ Files used in configuring a software package:
+
+ <PRE>
+ .-------------> [config.cache]
+ configure* ------------+-------------> config.log
+ |
+ [config.h.in] -. v .-> [config.h] -.
+ +--> config.status* -+ +--> make*
+ Makefile.in ---' `-> Makefile ---'
+ </PRE>
+
+
+
+ <H2><A NAME="SEC7" HREF="autoconf_toc.html#TOC7">Writing <TT>`configure.ac'</TT></A></H2>
+
+ <P>
+ To produce a @command{configure} script for a software package, create a
+ file called <TT>`configure.ac'</TT> that contains invocations of the
+ Autoconf macros that test the system features your package needs or can
+ use. Autoconf macros already exist to check for many features; see
+ section <A HREF="autoconf.html#SEC35">Existing Tests</A>, for their descriptions. For most other features,
+ you can use Autoconf template macros to produce custom checks; see
+ section <A HREF="autoconf.html#SEC68">Writing Tests</A>, for information about them. For especially tricky
+ or specialized features, <TT>`configure.ac'</TT> might need to contain some
+ hand-crafted shell commands; see section <A HREF="autoconf.html#SEC110">Portable Shell Programming</A>. The
+ @command{autoscan} program can give you a good start in writing
+ <TT>`configure.ac'</TT> (see section <A HREF="autoconf.html#SEC11">Using @command{autoscan} to Create @file{configure.ac}</A>, for more information).
+
+
+ <P>
+ Previous versions of Autoconf promoted the name <TT>`configure.in'</TT>,
+ which is somewhat ambiguous (the tool needed to produce this file is not
+ described by its extension), and introduces a slight confusion with
+ <TT>`config.h.in'</TT> and so on (for which <SAMP>`.in'</SAMP> means "to be
+ processed by @command{configure}"). Using <TT>`configure.ac'</TT> is now
+ preferred.
+
+
+
+
+ <H3><A NAME="SEC8" HREF="autoconf_toc.html#TOC8">A Shell Script Compiler</A></H3>
+
+ <P>
+ Just as for any other computer language, in order to properly program
+ <TT>`configure.ac'</TT> in Autoconf you must understand <EM>what</EM> problem
+ the language tries to address and <EM>how</EM> it does so.
+
+
+ <P>
+ The problem Autoconf addresses is that the world is a mess. After all,
+ you are using Autoconf in order to have your package compile easily on
+ all sorts of different systems, some of them being extremely hostile.
+ Autoconf itself bears the price for these differences: @command{configure}
+ must run on all those systems, and thus @command{configure} must limit itself
+ to their lowest common denominator of features.
+
+
+ <P>
+ Naturally, you might then think of shell scripts; who needs
+ @command{autoconf}? A set of properly written shell functions is enough to
+ make it easy to write @command{configure} scripts by hand. Sigh!
+ Unfortunately, shell functions do not belong to the least common
+ denominator; therefore, where you would like to define a function and
+ use it ten times, you would instead need to copy its body ten times.
+
+
+ <P>
+ So, what is really needed is some kind of compiler, @command{autoconf},
+ that takes an Autoconf program, <TT>`configure.ac'</TT>, and transforms it
+ into a portable shell script, @command{configure}.
+
+
+ <P>
+ How does @command{autoconf} perform this task?
+
+
+ <P>
+ There are two obvious possibilities: creating a brand new language or
+ extending an existing one. The former option is very attractive: all
+ sorts of optimizations could easily be implemented in the compiler and
+ many rigorous checks could be performed on the Autoconf program
+ (e.g. rejecting any non-portable construct). Alternatively, you can
+ extend an existing language, such as the <CODE>sh</CODE> (Bourne shell)
+ language.
+
+
+ <P>
+ Autoconf does the latter: it is a layer on top of <CODE>sh</CODE>. It was
+ therefore most convenient to implement @command{autoconf} as a macro
+ expander: a program that repeatedly performs <EM>macro expansions</EM> on
+ text input, replacing macro calls with macro bodies and producing a pure
+ <CODE>sh</CODE> script in the end. Instead of implementing a dedicated
+ Autoconf macro expander, it is natural to use an existing
+ general-purpose macro language, such as M4, and implement the extensions
+ as a set of M4 macros.
+
+
+
+
+ <H3><A NAME="SEC9" HREF="autoconf_toc.html#TOC9">The Autoconf Language</A></H3>
+ <P>
+ <A NAME="IDX7"></A>
+
+
+ <P>
+ The Autoconf language is very different from many other computer
+ languages because it treats actual code the same as plain text. Whereas
+ in C, for instance, data and instructions have very different syntactic
+ status, in Autoconf their status is rigorously the same. Therefore, we
+ need a means to distinguish literal strings from text to be expanded:
+ quotation.
+
+
+ <P>
+ When calling macros that take arguments, there must not be any blank
+ space between the macro name and the open parenthesis. Arguments should
+ be enclosed within the M4 quote characters <SAMP>`['</SAMP> and <SAMP>`]'</SAMP>, and be
+ separated by commas. Any leading spaces in arguments are ignored,
+ unless they are quoted. You may safely leave out the quotes when the
+ argument is simple text, but <EM>always</EM> quote complex arguments such
+ as other macro calls. This rule applies recursively for every macro
+ call, including macros called from other macros.
+
+
+ <P>
+ For instance:
+
+
+
+ <PRE>
+ AC_CHECK_HEADER([stdio.h],
+ [AC_DEFINE([HAVE_STDIO_H])],
+ [AC_MSG_ERROR([Sorry, can't do anything for you])])
+ </PRE>
+
+ <P>
+ is quoted properly. You may safely simplify its quotation to:
+
+
+
+ <PRE>
+ AC_CHECK_HEADER(stdio.h,
+ [AC_DEFINE(HAVE_STDIO_H)],
+ [AC_MSG_ERROR([Sorry, can't do anything for you])])
+ </PRE>
+
+ <P>
+ Notice that the argument of <CODE>AC_MSG_ERROR</CODE> is still quoted;
+ otherwise, its comma would have been interpreted as an argument separator.
+
+
+ <P>
+ The following example is wrong and dangerous, as it is underquoted:
+
+
+
+ <PRE>
+ AC_CHECK_HEADER(stdio.h,
+ AC_DEFINE(HAVE_STDIO_H),
+ AC_MSG_ERROR([Sorry, can't do anything for you]))
+ </PRE>
+
+ <P>
+ In other cases, you may have to use text that also resembles a macro
+ call. You must quote that text even when it is not passed as a macro
+ argument:
+
+
+
+ <PRE>
+ echo "Hard rock was here! --[AC_DC]"
+ </PRE>
+
+ <P>
+ which will result in
+
+
+
+ <PRE>
+ echo "Hard rock was here! --AC_DC"
+ </PRE>
+
+ <P>
+ When you use the same text in a macro argument, you must therefore have
+ an extra quotation level (since one is stripped away by the macro
+ substitution). In general, then, it is a good idea to <EM>use double
+ quoting for all literal string arguments</EM>:
+
+
+
+ <PRE>
+ AC_MSG_WARN([[AC_DC stinks --Iron Maiden]])
+ </PRE>
+
+ <P>
+ You are now able to understand one of the constructs of Autoconf that
+ has been continually misunderstood... The rule of thumb is that
+ <EM>whenever you expect macro expansion, expect quote expansion</EM>;
+ i.e., expect one level of quotes to be lost. For instance:
+
+
+
+ <PRE>
+ AC_COMPILE_IFELSE([char b[10];],, [AC_MSG_ERROR([you lose])])
+ </PRE>
+
+ <P>
+ is incorrect: here, the first argument of <CODE>AC_COMPILE_IFELSE</CODE> is
+ <SAMP>`char b[10];'</SAMP> and will be expanded once, which results in
+ <SAMP>`char b10;'</SAMP>. (There was an idiom common in Autoconf's past to
+ address this issue via the M4 <CODE>changequote</CODE> primitive, but do not
+ use it!) Let's take a closer look: the author meant the first argument
+ to be understood as a literal, and therefore it must be quoted twice:
+
+
+
+ <PRE>
+ AC_COMPILE_IFELSE([[char b[10];]],, [AC_MSG_ERROR([you lose])])
+ </PRE>
+
+ <P>
+ Voil`a, you actually produce <SAMP>`char b[10];'</SAMP> this time!
+
+
+ <P>
+ The careful reader will notice that, according to these guidelines, the
+ "properly" quoted <CODE>AC_CHECK_HEADER</CODE> example above is actually
+ lacking three pairs of quotes! Nevertheless, for the sake of readability,
+ double quotation of literals is used only where needed in this manual.
+
+
+ <P>
+ Some macros take optional arguments, which this documentation represents
+ as @ovar{arg} (not to be confused with the quote characters). You may
+ just leave them empty, or use <SAMP>`[]'</SAMP> to make the emptiness of the
+ argument explicit, or you may simply omit the trailing commas. The
+ three lines below are equivalent:
+
+
+
+ <PRE>
+ AC_CHECK_HEADERS(stdio.h, [], [], [])
+ AC_CHECK_HEADERS(stdio.h,,,)
+ AC_CHECK_HEADERS(stdio.h)
+ </PRE>
+
+ <P>
+ It is best to put each macro call on its own line in
+ <TT>`configure.ac'</TT>. Most of the macros don't add extra newlines; they
+ rely on the newline after the macro call to terminate the commands.
+ This approach makes the generated @command{configure} script a little
+ easier to read by not inserting lots of blank lines. It is generally
+ safe to set shell variables on the same line as a macro call, because
+ the shell allows assignments without intervening newlines.
+
+
+ <P>
+ You can include comments in <TT>`configure.ac'</TT> files by starting them
+ with the <SAMP>`#'</SAMP>. For example, it is helpful to begin
+ <TT>`configure.ac'</TT> files with a line like this:
+
+
+
+ <PRE>
+ # Process this file with autoconf to produce a configure script.
+ </PRE>
+
+
+
+ <H3><A NAME="SEC10" HREF="autoconf_toc.html#TOC10">Standard <TT>`configure.ac'</TT> Layout</A></H3>
+
+ <P>
+ The order in which <TT>`configure.ac'</TT> calls the Autoconf macros is not
+ important, with a few exceptions. Every <TT>`configure.ac'</TT> must
+ contain a call to <CODE>AC_INIT</CODE> before the checks, and a call to
+ <CODE>AC_OUTPUT</CODE> at the end (see section <A HREF="autoconf.html#SEC19">Outputting Files</A>). Additionally, some macros
+ rely on other macros having been called first, because they check
+ previously set values of some variables to decide what to do. These
+ macros are noted in the individual descriptions (see section <A HREF="autoconf.html#SEC35">Existing Tests</A>), and they also warn you when @command{configure} is created if they
+ are called out of order.
+
+
+ <P>
+ To encourage consistency, here is a suggested order for calling the
+ Autoconf macros. Generally speaking, the things near the end of this
+ list are those that could depend on things earlier in it. For example,
+ library functions could be affected by types and libraries.
+
+
+
+ <PRE>
+ Autoconf requirements
+ <CODE>AC_INIT(<VAR>package</VAR>, <VAR>version</VAR>, <VAR>bug-report-address</VAR>)</CODE>
+ information on the package
+ checks for programs
+ checks for libraries
+ checks for header files
+ checks for types
+ checks for structures
+ checks for compiler characteristics
+ checks for library functions
+ checks for system services
+ <CODE>AC_CONFIG_FILES([<VAR>file...</VAR>])</CODE>
+ <CODE>AC_OUTPUT</CODE>
+ </PRE>
+
+
+
+ <H2><A NAME="SEC11" HREF="autoconf_toc.html#TOC11">Using @command{autoscan} to Create <TT>`configure.ac'</TT></A></H2>
+ <P>
+ <A NAME="IDX8"></A>
+
+
+ <P>
+ The @command{autoscan} program can help you create and/or maintain a
+ <TT>`configure.ac'</TT> file for a software package. @command{autoscan}
+ examines source files in the directory tree rooted at a directory given
+ as a command line argument, or the current directory if none is given.
+ It searches the source files for common portability problems and creates
+ a file <TT>`configure.scan'</TT> which is a preliminary <TT>`configure.ac'</TT>
+ for that package, and checks a possibly existing <TT>`configure.ac'</TT> for
+ completeness.
+
+
+ <P>
+ When using @command{autoscan} to create a <TT>`configure.ac'</TT>, you
+ should manually examine <TT>`configure.scan'</TT> before renaming it to
+ <TT>`configure.ac'</TT>; it will probably need some adjustments.
+ Occasionally, @command{autoscan} outputs a macro in the wrong order
+ relative to another macro, so that @command{autoconf} produces a warning;
+ you need to move such macros manually. Also, if you want the package to
+ use a configuration header file, you must add a call to
+ <CODE>AC_CONFIG_HEADERS</CODE> (see section <A HREF="autoconf.html#SEC27">Configuration Header Files</A>). You might
+ also have to change or add some <CODE>#if</CODE> directives to your program in
+ order to make it work with Autoconf (see section <A HREF="autoconf.html#SEC12">Using @command{ifnames} to List Conditionals</A>, for
+ information about a program that can help with that job).
+
+
+ <P>
+ When using @command{autoscan} to maintain a <TT>`configure.ac'</TT>, simply
+ consider adding its suggestions. The file <TT>`autoscan.log'</TT> will
+ contain detailed information on why a macro is requested.
+
+
+ <P>
+ @command{autoscan} uses several data files (installed along with Autoconf)
+ to determine which macros to output when it finds particular symbols in
+ a package's source files. These data files all have the same format:
+ each line consists of a symbol, whitespace, and the Autoconf macro to
+ output if that symbol is encountered. Lines starting with <SAMP>`#'</SAMP> are
+ comments.
+
+
+ <P>
+ @command{autoscan} accepts the following options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+
+ <DT>@option{--verbose}
+ <DD>
+ <DT>@option{-v}
+ <DD>
+ Print the names of the files it examines and the potentially interesting
+ symbols it finds in them. This output can be voluminous.
+
+ <DT>@option{--include=<VAR>dir</VAR>}
+ <DD>
+ <DT>@option{-I <VAR>dir</VAR>}
+ <DD>
+ Also look for input files in <VAR>dir</VAR>. Multiple invocations
+ accumulate. Directories are browsed from last to first.
+ </DL>
+
+
+
+ <H2><A NAME="SEC12" HREF="autoconf_toc.html#TOC12">Using @command{ifnames} to List Conditionals</A></H2>
+ <P>
+ <A NAME="IDX9"></A>
+
+
+ <P>
+ @command{ifnames} can help you write <TT>`configure.ac'</TT> for a software
+ package. It prints the identifiers that the package already uses in C
+ preprocessor conditionals. If a package has already been set up to have
+ some portability, @command{ifnames} can thus help you figure out what its
+ @command{configure} needs to check for. It may help fill in some gaps in a
+ <TT>`configure.ac'</TT> generated by @command{autoscan} (see section <A HREF="autoconf.html#SEC11">Using @command{autoscan} to Create @file{configure.ac}</A>).
+
+
+ <P>
+ @command{ifnames} scans all of the C source files named on the command line
+ (or the standard input, if none are given) and writes to the standard
+ output a sorted list of all the identifiers that appear in those files
+ in <CODE>#if</CODE>, <CODE>#elif</CODE>, <CODE>#ifdef</CODE>, or <CODE>#ifndef</CODE>
+ directives. It prints each identifier on a line, followed by a
+ space-separated list of the files in which that identifier occurs.
+
+
+ <P>
+ @command{ifnames} accepts the following options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+ </DL>
+
+
+
+ <H2><A NAME="SEC13" HREF="autoconf_toc.html#TOC13">Using @command{autoconf} to Create @command{configure}</A></H2>
+ <P>
+ <A NAME="IDX10"></A>
+
+
+ <P>
+ To create @command{configure} from <TT>`configure.ac'</TT>, run the
+ @command{autoconf} program with no arguments. @command{autoconf} processes
+ <TT>`configure.ac'</TT> with the <CODE>m4</CODE> macro processor, using the
+ Autoconf macros. If you give @command{autoconf} an argument, it reads that
+ file instead of <TT>`configure.ac'</TT> and writes the configuration script
+ to the standard output instead of to @command{configure}. If you give
+ @command{autoconf} the argument @option{-}, it reads from the standard
+ input instead of <TT>`configure.ac'</TT> and writes the configuration script
+ to the standard output.
+
+
+ <P>
+ The Autoconf macros are defined in several files. Some of the files are
+ distributed with Autoconf; @command{autoconf} reads them first. Then it
+ looks for the optional file <TT>`acsite.m4'</TT> in the directory that
+ contains the distributed Autoconf macro files, and for the optional file
+ <TT>`aclocal.m4'</TT> in the current directory. Those files can contain
+ your site's or the package's own Autoconf macro definitions
+ (see section <A HREF="autoconf.html#SEC101">Writing Autoconf Macros</A>, for more information). If a macro is
+ defined in more than one of the files that @command{autoconf} reads, the
+ last definition it reads overrides the earlier ones.
+
+
+ <P>
+ @command{autoconf} accepts the following options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+
+ <DT>@option{--verbose}
+ <DD>
+ <DT>@option{-v}
+ <DD>
+ Report processing steps.
+
+ <DT>@option{--debug}
+ <DD>
+ <DT>@option{-d}
+ <DD>
+ Don't remove the temporary files.
+
+ <DT>@option{--force}
+ <DD>
+ <DT>@option{-f}
+ <DD>
+ Remake <TT>`configure'</TT> even if newer than its input files.
+
+ <DT>@option{--include=<VAR>dir</VAR>}
+ <DD>
+ <DT>@option{-I <VAR>dir</VAR>}
+ <DD>
+ Also look for input files in <VAR>dir</VAR>. Multiple invocations
+ accumulate. Directories are browsed from last to first.
+
+ <DT>@option{--output=<VAR>file</VAR>}
+ <DD>
+ <DT>@option{-o <VAR>file</VAR>}
+ <DD>
+ Save output (script or trace) to <VAR>file</VAR>. The file @option{-} stands
+ for the standard output.
+
+ <DT>@option{--warnings=<VAR>category</VAR>}
+ <DD>
+ <DT>@option{-W <VAR>category</VAR>}
+ <DD>
+ <A NAME="IDX11"></A>
+ Report the warnings related to <VAR>category</VAR> (which can actually be a
+ comma separated list). See section <A HREF="autoconf.html#SEC104">Reporting Messages</A>, macro
+ <CODE>AC_DIAGNOSE</CODE>, for a comprehensive list of categories. Special
+ values include:
+
+ <DL COMPACT>
+
+ <DT><SAMP>`all'</SAMP>
+ <DD>
+ report all the warnings
+
+ <DT><SAMP>`none'</SAMP>
+ <DD>
+ report none
+
+ <DT><SAMP>`error'</SAMP>
+ <DD>
+ treats warnings as errors
+
+ <DT><SAMP>`no-<VAR>category</VAR>'</SAMP>
+ <DD>
+ disable warnings falling into <VAR>category</VAR>
+ </DL>
+
+ Warnings about <SAMP>`syntax'</SAMP> are enabled by default, and the environment
+ variable <CODE>WARNINGS</CODE>, a comma separated list of categories, is
+ honored. @command{autoconf -W <VAR>category</VAR>} will actually
+ behave as if you had run:
+
+
+ <PRE>
+ autoconf --warnings=syntax,$WARNINGS,<VAR>category</VAR>
+ </PRE>
+
+ If you want to disable @command{autoconf}'s defaults and <CODE>WARNINGS</CODE>,
+ but (for example) enable the warnings about obsolete constructs, you
+ would use @option{-W none,obsolete}.
+
+ <A NAME="IDX12"></A>
+ <A NAME="IDX13"></A>
+ @command{autoconf} displays a back trace for errors, but not for
+ warnings; if you want them, just pass @option{-W error}. For instance,
+ on this <TT>`configure.ac'</TT>:
+
+
+ <PRE>
+ AC_DEFUN([INNER],
+ [AC_TRY_RUN([exit (0)])])
+
+ AC_DEFUN([OUTER],
+ [INNER])
+
+ AC_INIT
+ OUTER
+ </PRE>
+
+ you get:
+
+
+ <PRE>
+ $ <KBD>autoconf -Wcross</KBD>
+ configure.ac:8: warning: AC_TRY_RUN called without default \
+ to allow cross compiling
+ $ <KBD>autoconf -Wcross,error</KBD>
+ configure.ac:8: error: AC_TRY_RUN called without default \
+ to allow cross compiling
+ acgeneral.m4:3044: AC_TRY_RUN is expanded from...
+ configure.ac:2: INNER is expanded from...
+ configure.ac:5: OUTER is expanded from...
+ configure.ac:8: the top level
+ </PRE>
+
+ <DT>@option{--trace=<VAR>macro</VAR>[:<VAR>format</VAR>]}
+ <DD>
+ <DT>@option{-t <VAR>macro</VAR>[:<VAR>format</VAR>]}
+ <DD>
+ Do not create the @command{configure} script, but list the calls to
+ <VAR>macro</VAR> according to the <VAR>format</VAR>. Multiple @option{--trace}
+ arguments can be used to list several macros. Multiple @option{--trace}
+ arguments for a single macro are not cumulative; instead, you should
+ just make <VAR>format</VAR> as long as needed.
+
+ The <VAR>format</VAR> is a regular string, with newlines if desired, and
+ several special escape codes. It defaults to <SAMP>`$f:$l:$n:$%'</SAMP>; see
+ below for details on the <VAR>format</VAR>.
+
+ <DT>@option{--initialization}
+ <DD>
+ <DT>@option{-i}
+ <DD>
+ By default, @option{--trace} does not trace the initialization of the
+ Autoconf macros (typically the <CODE>AC_DEFUN</CODE> definitions). This
+ results in a noticeable speedup, but can be disabled by this option.
+ </DL>
+
+ <P>
+ It is often necessary to check the content of a <TT>`configure.ac'</TT>
+ file, but parsing it yourself is extremely fragile and error-prone. It
+ is suggested that you rely upon @option{--trace} to scan
+ <TT>`configure.ac'</TT>.
+
+
+ <P>
+ The <VAR>format</VAR> of @option{--trace} can use the following special
+ escapes:
+
+
+ <DL COMPACT>
+
+ <DT><SAMP>`$$'</SAMP>
+ <DD>
+ The character <SAMP>`$'</SAMP>.
+
+ <DT><SAMP>`$f'</SAMP>
+ <DD>
+ The filename from which <VAR>macro</VAR> is called.
+
+ <DT><SAMP>`$l'</SAMP>
+ <DD>
+ The line number from which <VAR>macro</VAR> is called.
+
+ <DT><SAMP>`$d'</SAMP>
+ <DD>
+ The depth of the <VAR>macro</VAR> call. This is an M4 technical detail that
+ you probably don't want to know about.
+
+ <DT><SAMP>`$n'</SAMP>
+ <DD>
+ The name of the <VAR>macro</VAR>.
+
+ <DT><SAMP>`$<VAR>num</VAR>'</SAMP>
+ <DD>
+ The <VAR>num</VAR>th argument of the call to <VAR>macro</VAR>.
+
+ <DT><SAMP>`$@'</SAMP>
+ <DD>
+ <DT><SAMP>`$<VAR>sep</VAR>@'</SAMP>
+ <DD>
+ <DT><SAMP>`${<VAR>separator</VAR>}@'</SAMP>
+ <DD>
+ All the arguments passed to <VAR>macro</VAR>, separated by the character
+ <VAR>sep</VAR> or the string <VAR>separator</VAR> (<SAMP>`,'</SAMP> by default). Each
+ argument is quoted, i.e. enclosed in a pair of square brackets.
+
+ <DT><SAMP>`$*'</SAMP>
+ <DD>
+ <DT><SAMP>`$<VAR>sep</VAR>*'</SAMP>
+ <DD>
+ <DT><SAMP>`${<VAR>separator</VAR>}*'</SAMP>
+ <DD>
+ As above, but the arguments are not quoted.
+
+ <DT><SAMP>`$%'</SAMP>
+ <DD>
+ <DT><SAMP>`$<VAR>sep</VAR>%'</SAMP>
+ <DD>
+ <DT><SAMP>`${<VAR>separator</VAR>}%'</SAMP>
+ <DD>
+ As above, but the arguments are not quoted, all new line characters in
+ the arguments are smashed, and the default separator is <SAMP>`:'</SAMP>.
+
+ The escape <SAMP>`$%'</SAMP> produces single-line trace outputs (unless you put
+ newlines in the <SAMP>`separator'</SAMP>), while <SAMP>`$@'</SAMP> and <SAMP>`$*'</SAMP> do
+ not.
+ </DL>
+
+ <P>
+ For instance, to find the list of variables that are substituted, use:
+
+
+
+ <PRE>
+ $ <KBD>autoconf -t AC_SUBST</KBD>
+ configure.ac:2:AC_SUBST:ECHO_C
+ configure.ac:2:AC_SUBST:ECHO_N
+ configure.ac:2:AC_SUBST:ECHO_T
+ <I>More traces deleted</I>
+ </PRE>
+
+ <P>
+ The example below highlights the difference between <SAMP>`$@'</SAMP>,
+ <SAMP>`$*'</SAMP>, and <STRONG>$%</STRONG>.
+
+
+
+ <PRE>
+ $ <KBD>cat configure.ac</KBD>
+ AC_DEFINE(This, is, [an
+ [example]])
+ $ <KBD>autoconf -t 'AC_DEFINE:@: $@</KBD>
+ *: $*
+ $: $%'
+ @: [This],[is],[an
+ [example]]
+ *: This,is,an
+ [example]
+ $: This:is:an [example]
+ </PRE>
+
+ <P>
+ The <VAR>format</VAR> gives you a lot of freedom:
+
+
+
+ <PRE>
+ $ <KBD>autoconf -t 'AC_SUBST:$$ac_subst{"$1"} = "$f:$l";'</KBD>
+ $ac_subst{"ECHO_C"} = "configure.ac:2";
+ $ac_subst{"ECHO_N"} = "configure.ac:2";
+ $ac_subst{"ECHO_T"} = "configure.ac:2";
+ <I>More traces deleted</I>
+ </PRE>
+
+ <P>
+ A long <VAR>separator</VAR> can be used to improve the readability of complex
+ structures, and to ease its parsing (for instance when no single
+ character is suitable as a separator)):
+
+
+
+ <PRE>
+ $ <KBD>autoconf -t 'AM_MISSING_PROG:${|:::::|}*'</KBD>
+ ACLOCAL|:::::|aclocal|:::::|$missing_dir
+ AUTOCONF|:::::|autoconf|:::::|$missing_dir
+ AUTOMAKE|:::::|automake|:::::|$missing_dir
+ <I>More traces deleted</I>
+ </PRE>
+
+
+
+ <H2><A NAME="SEC14" HREF="autoconf_toc.html#TOC14">Using @command{autoreconf} to Update @command{configure} Scripts</A></H2>
+ <P>
+ <A NAME="IDX14"></A>
+
+
+ <P>
+ Installing the various components of the GNU Build System can be
+ tedious: running @command{gettextize}, @command{automake} etc. in each
+ directory. It may be needed either because some tools such as
+ @command{automake} have been updated on your system, or because some of
+ the sources such as <TT>`configure.ac'</TT> have been updated, or finally,
+ simply in order to install the GNU Build System in a fresh tree.
+
+
+ <P>
+ It runs @command{autoconf}, @command{autoheader}, @command{aclocal},
+ @command{automake}, @command{libtoolize}, and @command{gettextize} (when
+ appropriate) repeatedly to update the GNU Build System in specified
+ directories, and their subdirectories (see section <A HREF="autoconf.html#SEC33">Configuring Other Packages in Subdirectories</A>). By
+ default, it only remakes those files that are older than their sources.
+
+
+ <P>
+ If you install a new version of some tools, you can make
+ @command{autoreconf} remake <EM>all</EM> of the files by giving it the
+ @option{--force} option.
+
+
+ <P>
+ See section <A HREF="autoconf.html#SEC26">Automatic Remaking</A>, for <TT>`Makefile'</TT> rules to automatically
+ remake @command{configure} scripts when their source files change. That
+ method handles the timestamps of configuration header templates
+ properly, but does not pass @option{--autoconf-dir=<VAR>dir</VAR>} or
+ @option{--localdir=<VAR>dir</VAR>}.
+
+
+ <P>
+ @command{autoreconf} accepts the following options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+
+ <DT>@option{--verbose}
+ <DD>
+ Print the name of each directory where @command{autoreconf} runs
+ @command{autoconf} (and @command{autoheader}, if appropriate).
+
+ <DT>@option{--debug}
+ <DD>
+ <DT>@option{-d}
+ <DD>
+ Don't remove the temporary files.
+
+ <DT>@option{--force}
+ <DD>
+ <DT>@option{-f}
+ <DD>
+ Remake even <TT>`configure'</TT> scripts and configuration headers that are
+ newer than their input files (<TT>`configure.ac'</TT> and, if present,
+ <TT>`aclocal.m4'</TT>).
+
+ <DT>@option{--install}
+ <DD>
+ <DT>@option{-i}
+ <DD>
+ Copy missing auxiliary files. This option is similar to the option
+ <CODE>--add-missing</CODE> in @command{automake}.
+
+ <DT>@option{--symlink}
+ <DD>
+ <DT>@option{-s}
+ <DD>
+ Instead of copying missing auxiliary files, install symbolic links.
+
+ <DT>@option{--include=<VAR>dir</VAR>}
+ <DD>
+ <DT>@option{-I <VAR>dir</VAR>}
+ <DD>
+ Also look for input files in <VAR>dir</VAR>. Multiple invocations
+ accumulate. Directories are browsed from last to first.
+ </DL>
+
+
+
+ <H1><A NAME="SEC15" HREF="autoconf_toc.html#TOC15">Initialization and Output Files</A></H1>
+
+ <P>
+ Autoconf-generated @command{configure} scripts need some information about
+ how to initialize, such as how to find the package's source files; and
+ about the output files to produce. The following sections describe
+ initialization and the creation of output files.
+
+
+
+
+ <H2><A NAME="SEC16" HREF="autoconf_toc.html#TOC16">Initializing @command{configure}</A></H2>
+
+ <P>
+ Every @command{configure} script must call <CODE>AC_INIT</CODE> before doing
+ anything else. The only other required macro is <CODE>AC_OUTPUT</CODE>
+ (see section <A HREF="autoconf.html#SEC19">Outputting Files</A>).
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_INIT</B> <I>(<VAR>package</VAR>, <VAR>version</VAR>, @ovar{bug-report}, @ovar{tarname})</I>
+ <DD><A NAME="IDX15"></A>
+ <A NAME="IDX16"></A>
+ Process any command-line arguments and perform various initializations
+ and verifications.
+
+
+ <P>
+ Set the name of the <VAR>package</VAR> and its <VAR>version</VAR>. These are
+ typically used in @option{--version} support, including that of
+ @command{configure}. 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 latter is meant for
+ distribution tar ball names (e.g., <SAMP>`autoconf'</SAMP>). It defaults to
+ <VAR>package</VAR> once <SAMP>`GNU '</SAMP> strip, lower cased, and all non
+ alphanumeric character mapped onto <SAMP>`-'</SAMP>.
+
+
+ <P>
+ It is preferable that these arguments be static, i.e., there should not
+ be any shell computation, but they can be computed by M4. 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 then defined:
+
+
+ <DL COMPACT>
+
+ <DT><CODE>AC_PACKAGE_NAME</CODE>, <CODE>PACKAGE_NAME</CODE>
+ <DD>
+ <A NAME="IDX17"></A>
+ <A NAME="IDX18"></A>
+ <A NAME="IDX19"></A>
+ Exactly <VAR>package</VAR>.
+
+ <DT><CODE>AC_PACKAGE_TARNAME</CODE>, <CODE>PACKAGE_TARNAME</CODE>
+ <DD>
+ <A NAME="IDX20"></A>
+ <A NAME="IDX21"></A>
+ <A NAME="IDX22"></A>
+ Exactly <VAR>tarname</VAR>.
+
+ <DT><CODE>AC_PACKAGE_VERSION</CODE>, <CODE>PACKAGE_VERSION</CODE>
+ <DD>
+ <A NAME="IDX23"></A>
+ <A NAME="IDX24"></A>
+ <A NAME="IDX25"></A>
+ Exactly <VAR>version</VAR>.
+
+ <DT><CODE>AC_PACKAGE_STRING</CODE>, <CODE>PACKAGE_STRING</CODE>
+ <DD>
+ <A NAME="IDX26"></A>
+ <A NAME="IDX27"></A>
+ <A NAME="IDX28"></A>
+ Exactly <SAMP>`<VAR>package</VAR> <VAR>version</VAR>'</SAMP>.
+
+ <DT><CODE>AC_PACKAGE_BUGREPORT</CODE>, <CODE>PACKAGE_BUGREPORT</CODE>
+ <DD>
+ <A NAME="IDX29"></A>
+ <A NAME="IDX30"></A>
+ <A NAME="IDX31"></A>
+ Exactly <VAR>bug-report</VAR>.
+ </DL>
+ </DL>
+
+
+
+ <H2><A NAME="SEC17" HREF="autoconf_toc.html#TOC17">Notices in @command{configure}</A></H2>
+
+ <P>
+ The following macros manage version numbers for @command{configure}
+ scripts. Using them is optional.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PREREQ</B> <I>(<VAR>version</VAR>)</I>
+ <DD><A NAME="IDX32"></A>
+ <A NAME="IDX33"></A>
+ <A NAME="IDX34"></A>
+ Ensure that a recent enough version of Autoconf is being used. If the
+ version of Autoconf being used to create @command{configure} is earlier
+ than <VAR>version</VAR>, print an error message to the standard error output
+ and do not create @command{configure}. For example:
+
+
+
+ <PRE>
+ AC_PREREQ(2.53)
+ </PRE>
+
+ <P>
+ This macro is the only macro that may be used before <CODE>AC_INIT</CODE>, but
+ for consistency, you are invited not to do so.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_COPYRIGHT</B> <I>(<VAR>copyright-notice</VAR>)</I>
+ <DD><A NAME="IDX35"></A>
+ <A NAME="IDX36"></A>
+ <A NAME="IDX37"></A>
+ State that, in addition to the Free Software Foundation's copyright on
+ the Autoconf macros, parts of your @command{configure} are covered by the
+ <VAR>copyright-notice</VAR>.
+
+
+ <P>
+ The <VAR>copyright-notice</VAR> will show up in both the head of
+ @command{configure} and in <SAMP>`configure --version'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_REVISION</B> <I>(<VAR>revision-info</VAR>)</I>
+ <DD><A NAME="IDX38"></A>
+ <A NAME="IDX39"></A>
+ <A NAME="IDX40"></A>
+ Copy revision stamp <VAR>revision-info</VAR> into the @command{configure}
+ script, with any dollar signs or double-quotes removed. This macro lets
+ you put a revision stamp from <TT>`configure.ac'</TT> into @command{configure}
+ without RCS or <CODE>cvs</CODE> changing it when you check in
+ @command{configure}. That way, you can determine easily which revision of
+ <TT>`configure.ac'</TT> a particular @command{configure} corresponds to.
+
+
+ <P>
+ For example, this line in <TT>`configure.ac'</TT>:
+
+
+
+ <PRE>
+ AC_REVISION($Revision: 1.1 $)
+ </PRE>
+
+ <P>
+ produces this in @command{configure}:
+
+
+
+ <PRE>
+ #! /bin/sh
+ # From configure.ac Revision: 1.30
+ </PRE>
+
+ </DL>
+
+
+
+ <H2><A NAME="SEC18" HREF="autoconf_toc.html#TOC18">Finding @command{configure} Input</A></H2>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_SRCDIR</B> <I>(<VAR>unique-file-in-source-dir</VAR>)</I>
+ <DD><A NAME="IDX41"></A>
+ <A NAME="IDX42"></A>
+ <VAR>unique-file-in-source-dir</VAR> is some file that is in the package's
+ source directory; @command{configure} 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 @option{--srcdir}; this is a safety check. See section <A HREF="autoconf.html#SEC144">@command{configure} Invocation</A>, for more information.
+ </DL>
+
+
+ <P>
+ Packages that do manual configuration or use the <CODE>install</CODE> program
+ might need to tell @command{configure} where to find some other shell
+ scripts by calling <CODE>AC_CONFIG_AUX_DIR</CODE>, though the default places
+ it looks are correct for most cases.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_AUX_DIR</B> <I>(<VAR>dir</VAR>)</I>
+ <DD><A NAME="IDX43"></A>
+ <A NAME="IDX44"></A>
+ Use the auxiliary build tools (e.g., <TT>`install-sh'</TT>,
+ <TT>`config.sub'</TT>, <TT>`config.guess'</TT>, Cygnus @command{configure},
+ 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 @command{make} have a rule that creates
+ <TT>`install'</TT> from it if there is no <TT>`Makefile'</TT>.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC19" HREF="autoconf_toc.html#TOC19">Outputting Files</A></H2>
+
+ <P>
+ Every Autoconf script, e.g., <TT>`configure.ac'</TT>, should finish by
+ calling <CODE>AC_OUTPUT</CODE>. It is the macro that generates
+ <TT>`config.status'</TT>, which will create the <TT>`Makefile'</TT>s and any
+ other files resulting from configuration. The only required macro is
+ <CODE>AC_INIT</CODE> (see section <A HREF="autoconf.html#SEC18">Finding @command{configure} Input</A>).
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_OUTPUT</B>
+ <DD><A NAME="IDX45"></A>
+ <A NAME="IDX46"></A>
+ <A NAME="IDX47"></A>
+ Generate <TT>`config.status'</TT> and launch it. Call this macro once, at
+ the end of <TT>`configure.ac'</TT>.
+
+
+ <P>
+ <TT>`config.status'</TT> will take all the configuration actions: all the
+ output files (see section <A HREF="autoconf.html#SEC21">Creating Configuration Files</A>, macro
+ <CODE>AC_CONFIG_FILES</CODE>), header files (see section <A HREF="autoconf.html#SEC27">Configuration Header Files</A>,
+ macro <CODE>AC_CONFIG_HEADERS</CODE>), commands (see section <A HREF="autoconf.html#SEC31">Running Arbitrary Configuration Commands</A>, macro <CODE>AC_CONFIG_COMMANDS</CODE>), links (see
+ section <A HREF="autoconf.html#SEC32">Creating Configuration Links</A>, macro <CODE>AC_CONFIG_LINKS</CODE>), subdirectories
+ to configure (see section <A HREF="autoconf.html#SEC33">Configuring Other Packages in Subdirectories</A>, macro <CODE>AC_CONFIG_SUBDIRS</CODE>)
+ are honored.
+ </DL>
+
+
+ <P>
+ Historically, the usage of <CODE>AC_OUTPUT</CODE> was somewhat different.
+ See section <A HREF="autoconf.html#SEC150">Obsolete Macros</A>, for a description of the arguments that
+ <CODE>AC_OUTPUT</CODE> used to support.
+
+
+ <P>
+ If you run <CODE>make</CODE> on subdirectories, you should run it using the
+ <CODE>make</CODE> variable <CODE>MAKE</CODE>. Most versions of <CODE>make</CODE> set
+ <CODE>MAKE</CODE> to the name of the <CODE>make</CODE> program plus any options it
+ was given. (But many do not include in it the values of any variables
+ set on the command line, so those are not passed on automatically.)
+ Some old versions of <CODE>make</CODE> do not set this variable. The
+ following macro allows you to use it even with those versions.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_MAKE_SET</B>
+ <DD><A NAME="IDX48"></A>
+ <A NAME="IDX49"></A>
+ <A NAME="IDX50"></A>
+ If <CODE>make</CODE> predefines the variable <CODE>MAKE</CODE>, define output
+ variable <CODE>SET_MAKE</CODE> to be empty. Otherwise, define <CODE>SET_MAKE</CODE>
+ to contain <SAMP>`MAKE=make'</SAMP>. Calls <CODE>AC_SUBST</CODE> for <CODE>SET_MAKE</CODE>.
+ </DL>
+
+
+ <P>
+ To use this macro, place a line like this in each <TT>`Makefile.in'</TT>
+ that runs <CODE>MAKE</CODE> on other directories:
+
+
+
+ <PRE>
+ @SET_MAKE@
+ </PRE>
+
+
+
+ <H2><A NAME="SEC20" HREF="autoconf_toc.html#TOC20">Taking Configuration Actions</A></H2>
+
+ <P>
+ <TT>`configure'</TT> is designed so that it appears to do everything itself,
+ but there is actually a hidden slave: <TT>`config.status'</TT>.
+ <TT>`configure'</TT> is in charge of examining your system, but it is
+ <TT>`config.status'</TT> that actually takes the proper actions based on the
+ results of <TT>`configure'</TT>. The most typical task of
+ <TT>`config.status'</TT> is to <EM>instantiate</EM> files.
+
+
+ <P>
+ This section describes the common behavior of the four standard
+ instantiating macros: <CODE>AC_CONFIG_FILES</CODE>, <CODE>AC_CONFIG_HEADERS</CODE>,
+ <CODE>AC_CONFIG_COMMANDS</CODE> and <CODE>AC_CONFIG_LINKS</CODE>. They all
+ have this prototype:
+
+
+
+ <PRE>
+ AC_CONFIG_FOOS(<VAR>tag</VAR>..., [<VAR>commands</VAR>], [<VAR>init-cmds</VAR>])
+ </PRE>
+
+ <P>
+ where the arguments are:
+
+
+ <DL COMPACT>
+
+ <DT><VAR><VAR>tag</VAR>...</VAR>
+ <DD>
+ A whitespace-separated list of tags, which are typically the names of
+ the files to instantiate.
+
+ You are encouraged to use literals as <VAR>tags</VAR>. In particular, you
+ should avoid
+
+
+ <PRE>
+ ... && my_foos="$my_foos fooo"
+ ... && my_foos="$my_foos foooo"
+ AC_CONFIG_FOOS($my_foos)
+ </PRE>
+
+ and use this instead:
+
+
+ <PRE>
+ ... && AC_CONFIG_FOOS(fooo)
+ ... && AC_CONFIG_FOOS(foooo)
+ </PRE>
+
+ The macros <CODE>AC_CONFIG_FILES</CODE> and <CODE>AC_CONFIG_HEADERS</CODE> use
+ special <VAR>tag</VAR>s: they may have the form <SAMP>`<VAR>output</VAR>'</SAMP> or
+ <SAMP>`<VAR>output</VAR>:<VAR>inputs</VAR>'</SAMP>. The file <VAR>output</VAR> is instantiated
+ from its templates, <VAR>inputs</VAR> (defaulting to <SAMP>`<VAR>output</VAR>.in'</SAMP>).
+
+ For instance
+ <SAMP>`AC_CONFIG_FILES(Makefile:boiler/top.mk:boiler/bot.mk)'</SAMP> asks for
+ the creation of <TT>`Makefile'</TT> that will be the expansion of the
+ output variables in the concatenation of <TT>`boiler/top.mk'</TT> and
+ <TT>`boiler/bot.mk'</TT>.
+
+ The special value <SAMP>`-'</SAMP> might be used to denote the standard output
+ when used in <VAR>output</VAR>, or the standard input when used in the
+ <VAR>inputs</VAR>. You most probably don't need to use this in
+ <TT>`configure.ac'</TT>, but it is convenient when using the command line
+ interface of <TT>`./config.status'</TT>, see section <A HREF="autoconf.html#SEC145">Recreating a Configuration</A>,
+ for more details.
+
+ The <VAR>inputs</VAR> may be absolute or relative filenames. In the latter
+ case they are first looked for in the build tree, and then in the source
+ tree.
+
+ <DT><VAR>commands</VAR>
+ <DD>
+ Shell commands output literally into <TT>`config.status'</TT>, and
+ associated with a tag that the user can use to tell <TT>`config.status'</TT>
+ which the commands to run. The commands are run each time a <VAR>tag</VAR>
+ request is given to <TT>`config.status'</TT>; typically, each time the file
+ <TT>`<VAR>tag</VAR>'</TT> is created.
+
+ The variable set during the execution of @command{configure} are
+ <EM>not</EM> available here: you first need to set them via the
+ <VAR>init-cmds</VAR>. Nonetheless the following variables are precomputed:
+
+ <DL COMPACT>
+
+ <DT><CODE>srcdir</CODE>
+ <DD>
+ The path from the top build directory to the top source directory. This
+ is what @command{configure}'s option @option{--srcdir} sets.
+
+ <DT><CODE>ac_top_srcdir</CODE>
+ <DD>
+ The path from the current build directory to the top source directory.
+
+ <DT><CODE>ac_top_builddir</CODE>
+ <DD>
+ The path from the current build directory to the top build directory.
+ It can be empty, or else ends with a slash, so that you may concatenate
+ it.
+
+ <DT><CODE>ac_srcdir</CODE>
+ <DD>
+ The path from the current build directory to the corresponding source
+ directory.
+ </DL>
+
+ The <EM>current</EM> directory refers to the directory (or
+ pseudo-directory) containing the input part of <VAR>tags</VAR>. For
+ instance, running
+
+
+ <PRE>
+ AC_CONFIG_COMMANDS([deep/dir/out:in/in.in], [...], [...])
+ </PRE>
+
+ with @option{--srcdir=../package} produces the following values:
+
+
+ <PRE>
+ # Argument of --srcdir
+ srcdir='../package'
+ # Reversing deep/dir
+ ac_top_builddir='../../'
+ # Concatenation of $ac_top_builddir and srcdir
+ ac_top_srcdir='../../../package'
+ # Concatenation of $ac_top_srcdir and deep/dir
+ ac_srcdir='../../../package/deep/dir'
+ </PRE>
+
+ independently of <SAMP>`in/in.in'</SAMP>.
+
+ <DT><VAR>init-cmds</VAR>
+ <DD>
+ Shell commands output <EM>unquoted</EM> near the beginning of
+ <TT>`config.status'</TT>, and executed each time <TT>`config.status'</TT> runs
+ (regardless of the tag). Because they are unquoted, for example,
+ <SAMP>`$var'</SAMP> will be output as the value of <CODE>var</CODE>. <VAR>init-cmds</VAR>
+ is typically used by <TT>`configure'</TT> to give <TT>`config.status'</TT> some
+ variables it needs to run the <VAR>commands</VAR>.
+
+ You should be extremely cautious in your variable names: all the
+ <VAR>init-cmds</VAR> share the same name space and may overwrite each other
+ in unpredictable ways. Sorry...
+ </DL>
+
+ <P>
+ All these macros can be called multiple times, with different
+ <VAR>tag</VAR>s, of course!
+
+
+
+
+ <H2><A NAME="SEC21" HREF="autoconf_toc.html#TOC21">Creating Configuration Files</A></H2>
+
+ <P>
+ Be sure to read the previous section, section <A HREF="autoconf.html#SEC20">Taking Configuration Actions</A>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_FILES</B> <I>(<VAR>file</VAR>..., @ovar{cmds}, @ovar{init-cmds})</I>
+ <DD><A NAME="IDX51"></A>
+ <A NAME="IDX52"></A>
+ 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 section <A HREF="autoconf.html#SEC20">Taking Configuration Actions</A>. See section <A HREF="autoconf.html#SEC22">Substitutions in Makefiles</A>, for more information on using
+ output variables. See section <A HREF="autoconf.html#SEC81">Setting Output Variables</A>, for more information
+ on creating them. This macro creates the directory that the file is in
+ if it doesn't exist. Usually, <TT>`Makefile'</TT>s are created this way,
+ but other files, such as <TT>`.gdbinit'</TT>, can be specified as well.
+
+
+ <P>
+ Typical calls to <CODE>AC_CONFIG_FILES</CODE> look like this:
+
+
+
+ <PRE>
+ AC_CONFIG_FILES([Makefile src/Makefile man/Makefile X/Imakefile])
+ AC_CONFIG_FILES([autoconf], [chmod +x autoconf])
+ </PRE>
+
+ <P>
+ You can override an input file name by appending to <VAR>file</VAR> a
+ colon-separated list of input files. Examples:
+
+
+
+ <PRE>
+ AC_CONFIG_FILES([Makefile:boiler/top.mk:boiler/bot.mk]
+ [lib/Makefile:boiler/lib.mk])
+ </PRE>
+
+ <P>
+ Doing this allows you to keep your file names acceptable to MS-DOS, or
+ to prepend and/or append boilerplate to the file.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC22" HREF="autoconf_toc.html#TOC22">Substitutions in Makefiles</A></H2>
+
+ <P>
+ Each subdirectory in a distribution that contains something to be
+ compiled or installed should come with a file <TT>`Makefile.in'</TT>, from
+ which @command{configure} will create a <TT>`Makefile'</TT> in that directory.
+ To create a <TT>`Makefile'</TT>, @command{configure} performs a simple variable
+ substitution, replacing occurrences of <SAMP>`@<VAR>variable</VAR>@'</SAMP> in
+ <TT>`Makefile.in'</TT> with the value that @command{configure} has determined
+ for that variable. Variables that are substituted into output files in
+ this way are called <EM>output variables</EM>. They are ordinary shell
+ variables that are set in @command{configure}. To make @command{configure}
+ substitute a particular variable into the output files, the macro
+ <CODE>AC_SUBST</CODE> must be called with that variable name as an argument.
+ Any occurrences of <SAMP>`@<VAR>variable</VAR>@'</SAMP> for other variables are
+ left unchanged. See section <A HREF="autoconf.html#SEC81">Setting Output Variables</A>, for more information
+ on creating output variables with <CODE>AC_SUBST</CODE>.
+
+
+ <P>
+ A software package that uses a @command{configure} script should be
+ distributed with a file <TT>`Makefile.in'</TT>, but no <TT>`Makefile'</TT>; that
+ way, the user has to properly configure the package for the local system
+ before compiling it.
+
+
+ <P>
+ See section `Makefile Conventions' in <CITE>The GNU Coding Standards</CITE>, for more information on what to put in
+ <TT>`Makefile'</TT>s.
+
+
+
+
+ <H3><A NAME="SEC23" HREF="autoconf_toc.html#TOC23">Preset Output Variables</A></H3>
+
+ <P>
+ Some output variables are preset by the Autoconf macros. Some of the
+ Autoconf macros set additional output variables, which are mentioned in
+ the descriptions for those macros. See section <A HREF="autoconf.html#SEC185">Output Variable Index</A>, for a
+ complete list of output variables. See section <A HREF="autoconf.html#SEC24">Installation Directory Variables</A>, for the list of the preset ones related to installation
+ directories. Below are listed the other preset ones. They all are
+ precious variables (see section <A HREF="autoconf.html#SEC81">Setting Output Variables</A>,
+ <CODE>AC_ARG_VAR</CODE>).
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CFLAGS</B>
+ <DD><A NAME="IDX53"></A>
+ <A NAME="IDX54"></A>
+ Debugging and optimization options for the C compiler. If it is not set
+ in the environment when @command{configure} runs, the default value is set
+ when you call <CODE>AC_PROG_CC</CODE> (or empty if you don't). @command{configure}
+ uses this variable when compiling programs to test for C features.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>configure_input</B>
+ <DD><A NAME="IDX55"></A>
+ <A NAME="IDX56"></A>
+ A comment saying that the file was generated automatically by
+ @command{configure} and giving the name of the input file.
+ <CODE>AC_OUTPUT</CODE> adds a comment line containing this variable to the top
+ of every <TT>`Makefile'</TT> it creates. For other files, you should
+ reference this variable in a comment at the top of each input file. For
+ example, an input shell script should begin like this:
+
+
+
+ <PRE>
+ #! /bin/sh
+ # @configure_input@
+ </PRE>
+
+ <P>
+ The presence of that line also reminds people editing the file that it
+ needs to be processed by @command{configure} in order to be used.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CPPFLAGS</B>
+ <DD><A NAME="IDX57"></A>
+ <A NAME="IDX58"></A>
+ Header file search directory (@option{-I<VAR>dir</VAR>}) and any other
+ miscellaneous options for the C and C++ preprocessors and compilers. If
+ it is not set in the environment when @command{configure} runs, the default
+ value is empty. @command{configure} uses this variable when compiling or
+ preprocessing programs to test for C and C++ features.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CXXFLAGS</B>
+ <DD><A NAME="IDX59"></A>
+ <A NAME="IDX60"></A>
+ Debugging and optimization options for the C++ compiler. If it is not
+ set in the environment when @command{configure} runs, the default value is
+ set when you call <CODE>AC_PROG_CXX</CODE> (or empty if you don't).
+ @command{configure} uses this variable when compiling programs to test for
+ C++ features.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>DEFS</B>
+ <DD><A NAME="IDX61"></A>
+ <A NAME="IDX62"></A>
+ @option{-D} options to pass to the C compiler. If <CODE>AC_CONFIG_HEADERS</CODE>
+ is called, @command{configure} replaces <SAMP>`@DEFS@'</SAMP> with
+ @option{-DHAVE_CONFIG_H} instead (see section <A HREF="autoconf.html#SEC27">Configuration Header Files</A>). This
+ variable is not defined while @command{configure} is performing its tests,
+ only when creating the output files. See section <A HREF="autoconf.html#SEC81">Setting Output Variables</A>, for
+ how to check the results of previous tests.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>ECHO_C</B>
+ <DD><A NAME="IDX63"></A>
+ <DT><U>Variable:</U> <B>ECHO_N</B>
+ <DD><A NAME="IDX64"></A>
+ <DT><U>Variable:</U> <B>ECHO_T</B>
+ <DD><A NAME="IDX65"></A>
+ <A NAME="IDX66"></A>
+ <A NAME="IDX67"></A>
+ <A NAME="IDX68"></A>
+ How does one suppress the trailing newline from <CODE>echo</CODE> for
+ question-answer message pairs? These variables provide a way:
+
+
+
+ <PRE>
+ echo $ECHO_N "And the winner is... $ECHO_C"
+ sleep 100000000000
+ echo "${ECHO_T}dead."
+ </PRE>
+
+ <P>
+ Some old and uncommon <CODE>echo</CODE> implementations offer no means to
+ achieve this, in which case <CODE>ECHO_T</CODE> is set to tab. You might not
+ want to use it.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>FFLAGS</B>
+ <DD><A NAME="IDX69"></A>
+ <A NAME="IDX70"></A>
+ Debugging and optimization options for the Fortran 77 compiler. If it
+ is not set in the environment when @command{configure} runs, the default
+ value is set when you call <CODE>AC_PROG_F77</CODE> (or empty if you don't).
+ @command{configure} uses this variable when compiling programs to test for
+ Fortran 77 features.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>LDFLAGS</B>
+ <DD><A NAME="IDX71"></A>
+ <A NAME="IDX72"></A>
+ Stripping (@option{-s}), path (@option{-L}), and any other miscellaneous
+ options for the linker. Don't use this variable to pass library names
+ (@option{-l}) to the linker, use <CODE>LIBS</CODE> instead. If it is not set
+ in the environment when @command{configure} runs, the default value is empty.
+ @command{configure} uses this variable when linking programs to test for
+ C, C++ and Fortran 77 features.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>LIBS</B>
+ <DD><A NAME="IDX73"></A>
+ <A NAME="IDX74"></A>
+ @option{-l} options to pass to the linker. The default value is empty,
+ but some Autoconf macros may prepend extra libraries to this variable if
+ those libraries are found and provide necessary functions, see
+ section <A HREF="autoconf.html#SEC43">Library Files</A>. @command{configure} uses this variable when linking
+ programs to test for C, C++ and Fortran 77 features.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>builddir</B>
+ <DD><A NAME="IDX75"></A>
+ <A NAME="IDX76"></A>
+ Rigorously equal to <SAMP>`.'</SAMP>. Added for symmetry only.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>abs_builddir</B>
+ <DD><A NAME="IDX77"></A>
+ <A NAME="IDX78"></A>
+ Absolute path of <CODE>builddir</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>top_builddir</B>
+ <DD><A NAME="IDX79"></A>
+ <A NAME="IDX80"></A>
+ The relative path to the top-level of the current build tree. In the
+ top-level directory, this is the same as <CODE>srcbuild</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>abs_top_builddir</B>
+ <DD><A NAME="IDX81"></A>
+ <A NAME="IDX82"></A>
+ Absolute path of <CODE>top_builddir</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>srcdir</B>
+ <DD><A NAME="IDX83"></A>
+ <A NAME="IDX84"></A>
+ The relative path to the directory that contains the source code for
+ that <TT>`Makefile'</TT>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>abs_srcdir</B>
+ <DD><A NAME="IDX85"></A>
+ <A NAME="IDX86"></A>
+ Absolute path of <CODE>srcdir</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>top_srcdir</B>
+ <DD><A NAME="IDX87"></A>
+ <A NAME="IDX88"></A>
+ The relative path to the top-level source code directory for the
+ package. In the top-level directory, this is the same as <CODE>srcdir</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>abs_top_srcdir</B>
+ <DD><A NAME="IDX89"></A>
+ <A NAME="IDX90"></A>
+ Absolute path of <CODE>top_srcdir</CODE>.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC24" HREF="autoconf_toc.html#TOC24">Installation Directory Variables</A></H3>
+
+ <P>
+ The following variables specify the directories where the package will
+ be installed, see section `Variables for Installation Directories' in <CITE>The GNU Coding Standards</CITE>, for more information.
+ See the end of this section for details on when and how to use these
+ variables.
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>bindir</B>
+ <DD><A NAME="IDX91"></A>
+ <A NAME="IDX92"></A>
+ The directory for installing executables that users run.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>datadir</B>
+ <DD><A NAME="IDX93"></A>
+ <A NAME="IDX94"></A>
+ The directory for installing read-only architecture-independent data.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>exec_prefix</B>
+ <DD><A NAME="IDX95"></A>
+ <A NAME="IDX96"></A>
+ The installation prefix for architecture-dependent files. By default
+ it's the same as <VAR>prefix</VAR>. You should avoid installing anything
+ directly to <VAR>exec_prefix</VAR>. However, the default value for
+ directories containing architecture-dependent files should be relative
+ to <VAR>exec_prefix</VAR>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>includedir</B>
+ <DD><A NAME="IDX97"></A>
+ <A NAME="IDX98"></A>
+ The directory for installing C header files.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>infodir</B>
+ <DD><A NAME="IDX99"></A>
+ <A NAME="IDX100"></A>
+ The directory for installing documentation in Info format.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>libdir</B>
+ <DD><A NAME="IDX101"></A>
+ <A NAME="IDX102"></A>
+ The directory for installing object code libraries.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>libexecdir</B>
+ <DD><A NAME="IDX103"></A>
+ <A NAME="IDX104"></A>
+ The directory for installing executables that other programs run.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>localstatedir</B>
+ <DD><A NAME="IDX105"></A>
+ <A NAME="IDX106"></A>
+ The directory for installing modifiable single-machine data.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>mandir</B>
+ <DD><A NAME="IDX107"></A>
+ <A NAME="IDX108"></A>
+ The top-level directory for installing documentation in man format.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>oldincludedir</B>
+ <DD><A NAME="IDX109"></A>
+ <A NAME="IDX110"></A>
+ The directory for installing C header files for non-gcc compilers.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>prefix</B>
+ <DD><A NAME="IDX111"></A>
+ <A NAME="IDX112"></A>
+ The common installation prefix for all files. If <VAR>exec_prefix</VAR>
+ is defined to a different value, <VAR>prefix</VAR> is used only for
+ architecture-independent files.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>sbindir</B>
+ <DD><A NAME="IDX113"></A>
+ <A NAME="IDX114"></A>
+ The directory for installing executables that system
+ administrators run.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>sharedstatedir</B>
+ <DD><A NAME="IDX115"></A>
+ <A NAME="IDX116"></A>
+ The directory for installing modifiable architecture-independent data.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>sysconfdir</B>
+ <DD><A NAME="IDX117"></A>
+ <A NAME="IDX118"></A>
+ The directory for installing read-only single-machine data.
+ </DL>
+
+
+ <P>
+ Most of these variables have values that rely on <CODE>prefix</CODE> or
+ <CODE>exec_prefix</CODE>. It is deliberate that the directory output
+ variables keep them unexpanded: typically <SAMP>`@datadir@'</SAMP> will be
+ replaced by <SAMP>`${prefix}/share'</SAMP>, not <SAMP>`/usr/local/share'</SAMP>.
+
+
+ <P>
+ This behavior is mandated by the GNU coding standards, so that when
+ the user runs:
+
+
+ <DL COMPACT>
+
+ <DT><SAMP>`make'</SAMP>
+ <DD>
+ she can still specify a different prefix from the one specified to
+ @command{configure}, in which case, if needed, the package shall hard
+ code dependencies corresponding to the make-specified prefix.
+
+ <DT><SAMP>`make install'</SAMP>
+ <DD>
+ she can specify a different installation location, in which case the
+ package <EM>must</EM> still depend on the location which was compiled in
+ (i.e., never recompile when <SAMP>`make install'</SAMP> is run). This is an
+ extremely important feature, as many people may decide to install all
+ the files of a package grouped together, and then install links from
+ the final locations to there.
+ </DL>
+
+ <P>
+ In order to support these features, it is essential that <CODE>datadir</CODE>
+ remains being defined as <SAMP>`${prefix}/share'</SAMP> to depend upon the
+ current value of <CODE>prefix</CODE>.
+
+
+ <P>
+ A corollary is that you should not use these variables except in
+ Makefiles. For instance, instead of trying to evaluate <CODE>datadir</CODE>
+ in <TT>`configure'</TT> and hardcoding it in Makefiles using
+ e.g. <SAMP>`AC_DEFINE_UNQUOTED(DATADIR, "$datadir")'</SAMP>, you should add
+ <SAMP>`-DDATADIR="$(datadir)"'</SAMP> to your <CODE>CPPFLAGS</CODE>.
+
+
+ <P>
+ Similarly you should not rely on <CODE>AC_OUTPUT_FILES</CODE> to replace
+ <CODE>datadir</CODE> and friends in your shell scripts and other files, rather
+ let @command{make} manage their replacement. For instance Autoconf
+ ships templates of its shell scripts ending with <SAMP>`.sh'</SAMP>, and uses
+ this Makefile snippet:
+
+
+
+ <PRE>
+ .sh:
+ rm -f $@ $@.tmp
+ sed 's,@datadir\@,$(pkgdatadir),g' $< >$@.tmp
+ chmod +x $@.tmp
+ mv $@.tmp $@
+ </PRE>
+
+ <P>
+ Three things are noteworthy:
+
+
+ <DL COMPACT>
+
+ <DT><SAMP>`@datadir\@'</SAMP>
+ <DD>
+ The backslash prevents @command{configure} from replacing
+ <SAMP>`@datadir@'</SAMP> in the sed expression itself.
+
+ <DT><SAMP>`$(pkgdatadir)'</SAMP>
+ <DD>
+ Don't use <SAMP>`@pkgdatadir@'</SAMP>! Use the matching makefile variable
+ instead.
+
+ <DT><SAMP>`,'</SAMP>
+ <DD>
+ Don't use <SAMP>`/'</SAMP> in the sed expression(s) since most probably the
+ variables you use, such as <SAMP>`$(pkgdatadir)'</SAMP>, will contain
+ some.
+ </DL>
+
+
+
+ <H3><A NAME="SEC25" HREF="autoconf_toc.html#TOC25">Build Directories</A></H3>
+
+ <P>
+ You can support compiling a software package for several architectures
+ simultaneously from the same copy of the source code. The object files
+ for each architecture are kept in their own directory.
+
+
+ <P>
+ To support doing this, <CODE>make</CODE> uses the <CODE>VPATH</CODE> variable to
+ find the files that are in the source directory. GNU <CODE>make</CODE>
+ and most other recent <CODE>make</CODE> programs can do this. Older
+ <CODE>make</CODE> programs do not support <CODE>VPATH</CODE>; when using them, the
+ source code must be in the same directory as the object files.
+
+
+ <P>
+ To support <CODE>VPATH</CODE>, each <TT>`Makefile.in'</TT> should contain two
+ lines that look like:
+
+
+
+ <PRE>
+ srcdir = @srcdir@
+ VPATH = @srcdir@
+ </PRE>
+
+ <P>
+ Do not set <CODE>VPATH</CODE> to the value of another variable, for example
+ <SAMP>`VPATH = $(srcdir)'</SAMP>, because some versions of <CODE>make</CODE> do not do
+ variable substitutions on the value of <CODE>VPATH</CODE>.
+
+
+ <P>
+ @command{configure} substitutes in the correct value for <CODE>srcdir</CODE> when
+ it produces <TT>`Makefile'</TT>.
+
+
+ <P>
+ Do not use the <CODE>make</CODE> variable <CODE>$<</CODE>, which expands to the
+ file name of the file in the source directory (found with <CODE>VPATH</CODE>),
+ except in implicit rules. (An implicit rule is one such as <SAMP>`.c.o'</SAMP>,
+ which tells how to create a <TT>`.o'</TT> file from a <TT>`.c'</TT> file.) Some
+ versions of <CODE>make</CODE> do not set <CODE>$<</CODE> in explicit rules; they
+ expand it to an empty value.
+
+
+ <P>
+ Instead, <TT>`Makefile'</TT> command lines should always refer to source
+ files by prefixing them with <SAMP>`$(srcdir)/'</SAMP>. For example:
+
+
+
+ <PRE>
+ time.info: time.texinfo
+ $(MAKEINFO) $(srcdir)/time.texinfo
+ </PRE>
+
+
+
+ <H3><A NAME="SEC26" HREF="autoconf_toc.html#TOC26">Automatic Remaking</A></H3>
+
+ <P>
+ You can put rules like the following in the top-level <TT>`Makefile.in'</TT>
+ for a package to automatically update the configuration information when
+ you change the configuration files. This example includes all of the
+ optional files, such as <TT>`aclocal.m4'</TT> and those related to
+ configuration header files. Omit from the <TT>`Makefile.in'</TT> rules for
+ any of these files that your package does not use.
+
+
+ <P>
+ The <SAMP>`$(srcdir)/'</SAMP> prefix is included because of limitations in the
+ <CODE>VPATH</CODE> mechanism.
+
+
+ <P>
+ The <TT>`stamp-'</TT> files are necessary because the timestamps of
+ <TT>`config.h.in'</TT> and <TT>`config.h'</TT> will not be changed if remaking
+ them does not change their contents. This feature avoids unnecessary
+ recompilation. You should include the file <TT>`stamp-h.in'</TT> your
+ package's distribution, so @command{make} will consider
+ <TT>`config.h.in'</TT> up to date. Don't use @command{touch}
+ (see section <A HREF="autoconf.html#SEC119">Limitations of Usual Tools</A>), rather use @command{echo} (using
+ @command{date} would cause needless differences, hence CVS
+ conflicts etc.).
+
+
+
+ <PRE>
+ $(srcdir)/configure: configure.ac aclocal.m4
+ cd $(srcdir) && autoconf
+
+ # autoheader might not change config.h.in, so touch a stamp file.
+ $(srcdir)/config.h.in: stamp-h.in
+ $(srcdir)/stamp-h.in: configure.ac aclocal.m4
+ cd $(srcdir) && autoheader
+ echo timestamp > $(srcdir)/stamp-h.in
+
+ config.h: stamp-h
+ stamp-h: config.h.in config.status
+ ./config.status
+
+ Makefile: Makefile.in config.status
+ ./config.status
+
+ config.status: configure
+ ./config.status --recheck
+ </PRE>
+
+ <P>
+ (Be careful if you copy these lines directly into your Makefile, as you
+ will need to convert the indented lines to start with the tab character.)
+
+
+ <P>
+ In addition, you should use <SAMP>`AC_CONFIG_FILES([stamp-h], [echo
+ timestamp > stamp-h])'</SAMP> so <TT>`config.status'</TT> will ensure that
+ <TT>`config.h'</TT> is considered up to date. See section <A HREF="autoconf.html#SEC19">Outputting Files</A>, for more
+ information about <CODE>AC_OUTPUT</CODE>.
+
+
+ <P>
+ See section <A HREF="autoconf.html#SEC145">Recreating a Configuration</A>, for more examples of handling
+ configuration-related dependencies.
+
+
+
+
+ <H2><A NAME="SEC27" HREF="autoconf_toc.html#TOC27">Configuration Header Files</A></H2>
+ <P>
+ <A NAME="IDX119"></A>
+ <A NAME="IDX120"></A>
+
+
+ <P>
+ When a package tests more than a few C preprocessor symbols, the command
+ lines to pass @option{-D} options to the compiler can get quite long.
+ This causes two problems. One is that the <CODE>make</CODE> output is hard to
+ visually scan for errors. More seriously, the command lines can exceed
+ the length limits of some operating systems. As an alternative to
+ passing @option{-D} options to the compiler, @command{configure} scripts can
+ create a C header file containing <SAMP>`#define'</SAMP> directives. The
+ <CODE>AC_CONFIG_HEADERS</CODE> macro selects this kind of output. It should
+ be called right after <CODE>AC_INIT</CODE>.
+
+
+ <P>
+ The package should <SAMP>`#include'</SAMP> the configuration header file before
+ any other header files, to prevent inconsistencies in declarations (for
+ example, if it redefines <CODE>const</CODE>). Use <SAMP>`#include <config.h>'</SAMP>
+ instead of <SAMP>`#include "config.h"'</SAMP>, and pass the C compiler a
+ @option{-I.} option (or @option{-I..}; whichever directory contains
+ <TT>`config.h'</TT>). That way, even if the source directory is configured
+ itself (perhaps to make a distribution), other build directories can
+ also be configured without finding the <TT>`config.h'</TT> from the source
+ directory.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_HEADERS</B> <I>(<VAR>header</VAR> ..., @ovar{cmds}, @ovar{init-cmds})</I>
+ <DD><A NAME="IDX121"></A>
+ <A NAME="IDX122"></A>
+ <A NAME="IDX123"></A>
+ This macro is one of the instantiating macros, see section <A HREF="autoconf.html#SEC20">Taking Configuration Actions</A>. Make <CODE>AC_OUTPUT</CODE> create the file(s) in the
+ whitespace-separated list <VAR>header</VAR> containing C preprocessor
+ <CODE>#define</CODE> statements, and replace <SAMP>`@DEFS@'</SAMP> in generated
+ files with @option{-DHAVE_CONFIG_H} instead of the value of <CODE>DEFS</CODE>.
+ The usual name for <VAR>header</VAR> is <TT>`config.h'</TT>.
+
+
+ <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
+ some changes in configuration without needlessly causing object files
+ that depend on the header file to be recompiled.
+
+
+ <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. Examples:
+
+
+
+ <PRE>
+ AC_CONFIG_HEADERS([config.h:config.hin])
+ AC_CONFIG_HEADERS([defines.h:defs.pre:defines.h.in:defs.post])
+ </PRE>
+
+ <P>
+ Doing this allows you to keep your file names acceptable to MS-DOS, or
+ to prepend and/or append boilerplate to the file.
+ </DL>
+
+
+ <P>
+ See section <A HREF="autoconf.html#SEC20">Taking Configuration Actions</A>, for more details on <VAR>header</VAR>.
+
+
+
+
+ <H3><A NAME="SEC28" HREF="autoconf_toc.html#TOC28">Configuration Header Templates</A></H3>
+ <P>
+ <A NAME="IDX124"></A>
+ <A NAME="IDX125"></A>
+
+
+ <P>
+ Your distribution should contain a template file that looks as you want
+ the final header file to look, including comments, with <CODE>#undef</CODE>
+ statements which are used as hooks. For example, suppose your
+ <TT>`configure.ac'</TT> makes these calls:
+
+
+
+ <PRE>
+ AC_CONFIG_HEADERS([conf.h])
+ AC_CHECK_HEADERS([unistd.h])
+ </PRE>
+
+ <P>
+ Then you could have code like the following in <TT>`conf.h.in'</TT>. On
+ systems that have <TT>`unistd.h'</TT>, @command{configure} will <SAMP>`#define'</SAMP>
+ <SAMP>`HAVE_UNISTD_H'</SAMP> to 1. On other systems, the whole line will be
+ commented out (in case the system predefines that symbol).
+
+
+
+ <PRE>
+ /* Define as 1 if you have unistd.h. */
+ #undef HAVE_UNISTD_H
+ </PRE>
+
+ <P>
+ You can then decode the configuration header using the preprocessor
+ directives:
+
+
+
+ <PRE>
+ #include <conf.h>
+
+ #if HAVE_UNISTD_H
+ # include <unistd.h>
+ #else
+ /* We are in trouble. */
+ #endif
+ </PRE>
+
+ <P>
+ The use of old form templates, with <SAMP>`#define'</SAMP> instead of
+ <SAMP>`#undef'</SAMP> is strongly discouraged.
+
+
+ <P>
+ Since it is a tedious task to keep a template header up to date, you may
+ use @command{autoheader} to generate it, see section <A HREF="autoconf.html#SEC29">Using @command{autoheader} to Create @file{config.h.in}</A>.
+
+
+
+
+ <H3><A NAME="SEC29" HREF="autoconf_toc.html#TOC29">Using @command{autoheader} to Create <TT>`config.h.in'</TT></A></H3>
+ <P>
+ <A NAME="IDX126"></A>
+
+
+ <P>
+ The @command{autoheader} program can create a template file of C
+ <SAMP>`#define'</SAMP> statements for @command{configure} to use. If
+ <TT>`configure.ac'</TT> invokes <CODE>AC_CONFIG_HEADERS(<VAR>file</VAR>)</CODE>,
+ @command{autoheader} creates <TT>`<VAR>file</VAR>.in'</TT>; if multiple file
+ arguments are given, the first one is used. Otherwise,
+ @command{autoheader} creates <TT>`config.h.in'</TT>.
+
+
+ <P>
+ In order to do its job, @command{autoheader} needs you to document all
+ of the symbols that you might use; i.e., there must be at least one
+ <CODE>AC_DEFINE</CODE> or one <CODE>AC_DEFINE_UNQUOTED</CODE> using its third
+ argument for each symbol (see section <A HREF="autoconf.html#SEC80">Defining C Preprocessor Symbols</A>). An additional
+ constraint is that the first argument of <CODE>AC_DEFINE</CODE> must be a
+ literal. Note that all symbols defined by Autoconf's built-in tests are
+ already documented properly; you only need to document those that you
+ define yourself.
+
+
+ <P>
+ You might wonder why @command{autoheader} is needed: after all, why
+ would @command{configure} need to "patch" a <TT>`config.h.in'</TT> to
+ produce a <TT>`config.h'</TT> instead of just creating <TT>`config.h'</TT> from
+ scratch? Well, when everything rocks, the answer is just that we are
+ wasting our time maintaining @command{autoheader}: generating
+ <TT>`config.h'</TT> directly is all that is needed. When things go wrong,
+ however, you'll be thankful for the existence of @command{autoheader}.
+
+
+ <P>
+ The fact that the symbols are documented is important in order to
+ <EM>check</EM> that <TT>`config.h'</TT> makes sense. The fact that there is a
+ well defined list of symbols that should be <CODE>#define</CODE>'d (or not) is
+ also important for people who are porting packages to environments where
+ @command{configure} cannot be run: they just have to @emph{fill in the
+ blanks}.
+
+
+ <P>
+ But let's come back to the point: @command{autoheader}'s invocation...
+
+
+ <P>
+ If you give @command{autoheader} an argument, it uses that file instead
+ of <TT>`configure.ac'</TT> and writes the header file to the standard output
+ instead of to <TT>`config.h.in'</TT>. If you give @command{autoheader} an
+ argument of @option{-}, it reads the standard input instead of
+ <TT>`configure.ac'</TT> and writes the header file to the standard output.
+
+
+ <P>
+ @command{autoheader} accepts the following options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+
+ <DT>@option{--verbose}
+ <DD>
+ <DT>@option{-v}
+ <DD>
+ Report processing steps.
+
+ <DT>@option{--debug}
+ <DD>
+ <DT>@option{-d}
+ <DD>
+ Don't remove the temporary files.
+
+ <DT>@option{--force}
+ <DD>
+ <DT>@option{-f}
+ <DD>
+ Remake the template file even if newer than its input files.
+
+ <DT>@option{--include=<VAR>dir</VAR>}
+ <DD>
+ <DT>@option{-I <VAR>dir</VAR>}
+ <DD>
+ Also look for input files in <VAR>dir</VAR>. Multiple invocations accumulate.
+ Directories are browsed from last to first.
+
+ <DT>@option{--warnings=<VAR>category</VAR>}
+ <DD>
+ <DT>@option{-W <VAR>category</VAR>}
+ <DD>
+ <A NAME="IDX127"></A>
+ Report the warnings related to <VAR>category</VAR> (which can actually be a
+ comma separated list). Current categories include:
+
+ <DL COMPACT>
+
+ <DT><SAMP>`obsolete'</SAMP>
+ <DD>
+ report the uses of obsolete constructs
+
+ <DT><SAMP>`all'</SAMP>
+ <DD>
+ report all the warnings
+
+ <DT><SAMP>`none'</SAMP>
+ <DD>
+ report none
+
+ <DT><SAMP>`error'</SAMP>
+ <DD>
+ treats warnings as errors
+
+ <DT><SAMP>`no-<VAR>category</VAR>'</SAMP>
+ <DD>
+ disable warnings falling into <VAR>category</VAR>
+ </DL>
+
+ </DL>
+
+
+
+ <H3><A NAME="SEC30" HREF="autoconf_toc.html#TOC30">Autoheader Macros</A></H3>
+
+ <P>
+ @command{autoheader} scans <TT>`configure.ac'</TT> and figures out which C
+ preprocessor symbols it might define. It knows how to generate
+ templates for symbols defined by <CODE>AC_CHECK_HEADERS</CODE>,
+ <CODE>AC_CHECK_FUNCS</CODE> etc., but if you <CODE>AC_DEFINE</CODE> any additional
+ symbol, you must define a template for it. If there are missing
+ templates, @command{autoheader} fails with an error message.
+
+
+ <P>
+ The simplest way to create a template for a <VAR>symbol</VAR> is to supply
+ the <VAR>description</VAR> argument to an <SAMP>`AC_DEFINE(<VAR>symbol</VAR>)'</SAMP>; see
+ section <A HREF="autoconf.html#SEC80">Defining C Preprocessor Symbols</A>. You may also use one of the following macros.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AH_VERBATIM</B> <I>(<VAR>key</VAR>, <VAR>template</VAR>)</I>
+ <DD><A NAME="IDX128"></A>
+ <A NAME="IDX129"></A>
+ <A NAME="IDX130"></A>
+ Tell @command{autoheader} 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 the symbol that can be <CODE>AC_DEFINE</CODE>'d.
+
+
+ <P>
+ For example:
+
+
+
+ <PRE>
+ AH_VERBATIM([_GNU_SOURCE],
+ [/* Enable GNU extensions on systems that have them. */
+ #ifndef _GNU_SOURCE
+ # define _GNU_SOURCE
+ #endif])
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AH_TEMPLATE</B> <I>(<VAR>key</VAR>, <VAR>description</VAR>)</I>
+ <DD><A NAME="IDX131"></A>
+ <A NAME="IDX132"></A>
+ <A NAME="IDX133"></A>
+ Tell @command{autoheader} 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>
+ For 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>
+
+ <P>
+ will generate the following template, with the description properly
+ justified.
+
+
+
+ <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>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AH_TOP</B> <I>(<VAR>text</VAR>)</I>
+ <DD><A NAME="IDX134"></A>
+ <A NAME="IDX135"></A>
+ <A NAME="IDX136"></A>
+ Include <VAR>text</VAR> at the top of the header template file.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AH_BOTTOM</B> <I>(<VAR>text</VAR>)</I>
+ <DD><A NAME="IDX137"></A>
+ <A NAME="IDX138"></A>
+ <A NAME="IDX139"></A>
+ Include <VAR>text</VAR> at the bottom of the header template file.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC31" HREF="autoconf_toc.html#TOC31">Running Arbitrary Configuration Commands</A></H2>
+
+ <P>
+ You execute arbitrary commands either before, during and after
+ <TT>`config.status'</TT> is run. The three following macros accumulate the
+ commands to run when they are called multiple times.
+ <CODE>AC_CONFIG_COMMANDS</CODE> replaces the obsolete macro
+ <CODE>AC_OUTPUT_COMMANDS</CODE>, see section <A HREF="autoconf.html#SEC150">Obsolete Macros</A>, for details.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_COMMANDS</B> <I>(<VAR>tag</VAR>..., @ovar{cmds}, @ovar{init-cmds})</I>
+ <DD><A NAME="IDX140"></A>
+ <A NAME="IDX141"></A>
+ Specify additional shell commands to run at the end of
+ <TT>`config.status'</TT>, and shell commands to initialize any variables
+ from @command{configure}. Associate the commands to the <VAR>tag</VAR>. Since
+ typically the <VAR>cmds</VAR> create a file, <VAR>tag</VAR> should naturally be
+ the name of that file. This macro is one of the instantiating macros,
+ see section <A HREF="autoconf.html#SEC20">Taking Configuration Actions</A>.
+
+
+ <P>
+ Here is an unrealistic example:
+
+ <PRE>
+ fubar=42
+ AC_CONFIG_COMMANDS([fubar],
+ [echo this is extra $fubar, and so on.],
+ [fubar=$fubar])
+ </PRE>
+
+ <P>
+ Here is a better one:
+
+ <PRE>
+ AC_CONFIG_COMMANDS([time-stamp], [date >time-stamp])
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_COMMANDS_PRE</B> <I>(<VAR>cmds</VAR>)</I>
+ <DD><A NAME="IDX142"></A>
+ <A NAME="IDX143"></A>
+ Execute the <VAR>cmds</VAR> right before creating <TT>`config.status'</TT>. A
+ typical use is computing values derived from variables built during the
+ execution of @command{configure}:
+
+
+
+ <PRE>
+ AC_CONFIG_COMMANDS_PRE(
+ [LTLIBOBJS=`echo $LIBOBJS | sed 's/\.o/\.lo/g'`
+ AC_SUBST(LTLIBOBJS)])
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_COMMANDS_POST</B> <I>(<VAR>cmds</VAR>)</I>
+ <DD><A NAME="IDX144"></A>
+ <A NAME="IDX145"></A>
+ Execute the <VAR>cmds</VAR> right after creating <TT>`config.status'</TT>.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC32" HREF="autoconf_toc.html#TOC32">Creating Configuration Links</A></H2>
+
+ <P>
+ You may find it convenient to create links whose destinations depend upon
+ results of tests. One can use <CODE>AC_CONFIG_COMMANDS</CODE> but the
+ creation of relative symbolic links can be delicate when the package is
+ built in another directory than its sources.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_LINKS</B> <I>(<VAR>dest</VAR>:<VAR>source</VAR>..., @ovar{cmds}, @ovar{init-cmds})</I>
+ <DD><A NAME="IDX146"></A>
+ <A NAME="IDX147"></A>
+ <A NAME="IDX148"></A>
+ 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. 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 section <A HREF="autoconf.html#SEC20">Taking Configuration Actions</A>.
+
+
+ <P>
+ For example, this call:
+
+
+
+ <PRE>
+ AC_CONFIG_LINKS(host.h:config/$machine.h
+ object.h:config/$obj_format.h)
+ </PRE>
+
+ <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>
+ 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>
+ One can then run:
+
+ <PRE>
+ ./config.status host.h object.h
+ </PRE>
+
+ <P>
+ to create the links.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC33" HREF="autoconf_toc.html#TOC33">Configuring Other Packages in Subdirectories</A></H2>
+
+ <P>
+ In most situations, calling <CODE>AC_OUTPUT</CODE> is sufficient to produce
+ <TT>`Makefile'</TT>s in subdirectories. However, @command{configure} scripts
+ that control more than one independent package can use
+ <CODE>AC_CONFIG_SUBDIRS</CODE> to run @command{configure} scripts for other
+ packages in subdirectories.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONFIG_SUBDIRS</B> <I>(<VAR>dir</VAR> ...)</I>
+ <DD><A NAME="IDX149"></A>
+ <A NAME="IDX150"></A>
+ <A NAME="IDX151"></A>
+ Make <CODE>AC_OUTPUT</CODE> run @command{configure} in each subdirectory
+ <VAR>dir</VAR> in the given whitespace-separated list. Each <VAR>dir</VAR> should
+ be a literal, i.e., please do not use:
+
+
+
+ <PRE>
+ if test "$package_foo_enabled" = yes; then
+ $my_subdirs="$my_subdirs foo"
+ fi
+ AC_CONFIG_SUBDIRS($my_subdirs)
+ </PRE>
+
+ <P>
+ because this prevents <SAMP>`./configure --help=recursive'</SAMP> from
+ displaying the options of the package <CODE>foo</CODE>. Rather, you should
+ write:
+
+
+
+ <PRE>
+ if test "$package_foo_enabled" = yes; then
+ AC_CONFIG_SUBDIRS(foo)
+ fi
+ </PRE>
+
+ <P>
+ If a given <VAR>dir</VAR> is not found, an error is reported: if the
+ subdirectory is optional, write:
+
+
+
+ <PRE>
+ if test -d $srcdir/foo; then
+ AC_CONFIG_SUBDIRS(foo)
+ fi
+ </PRE>
+
+ <P>
+ If a given <VAR>dir</VAR> contains @command{configure.gnu}, it is run instead
+ of @command{configure}. This is for packages that might use a
+ non-autoconf script @command{Configure}, which can't be called through a
+ wrapper @command{configure} since it would be the same file on
+ case-insensitive filesystems. Likewise, if a <VAR>dir</VAR> contains
+ <TT>`configure.ac'</TT> but no @command{configure}, the Cygnus
+ @command{configure} script found by <CODE>AC_CONFIG_AUX_DIR</CODE> is used.
+
+
+ <P>
+ The subdirectory @command{configure} scripts are given the same command
+ line options that were given to this @command{configure} script, with minor
+ changes if needed, which include:
+
+
+
+ <UL>
+ <LI>
+
+ adjusting a relative path for the cache file;
+
+ <LI>
+
+ adjusting a relative path for the source directory;
+
+ <LI>
+
+ propagating the current value of <CODE>$prefix</CODE>, including if it was
+ defaulted, and if default values of the top level and of sub directory
+ <TT>`configure'</TT> differ.
+ </UL>
+
+ <P>
+ This macro also sets the output variable <CODE>subdirs</CODE> to the list of
+ directories <SAMP>`<VAR>dir</VAR> ...'</SAMP>. <TT>`Makefile'</TT> rules can use
+ this variable to determine which subdirectories to recurse into. This
+ macro may be called multiple times.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC34" HREF="autoconf_toc.html#TOC34">Default Prefix</A></H2>
+
+ <P>
+ By default, @command{configure} sets the prefix for files it installs to
+ <TT>`/usr/local'</TT>. The user of @command{configure} can select a different
+ prefix using the @option{--prefix} and @option{--exec-prefix} options.
+ There are two ways to change the default: when creating
+ @command{configure}, and when running it.
+
+
+ <P>
+ Some software packages might want to install in a directory besides
+ <TT>`/usr/local'</TT> by default. To accomplish that, use the
+ <CODE>AC_PREFIX_DEFAULT</CODE> macro.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PREFIX_DEFAULT</B> <I>(<VAR>prefix</VAR>)</I>
+ <DD><A NAME="IDX152"></A>
+ <A NAME="IDX153"></A>
+ Set the default installation prefix to <VAR>prefix</VAR> instead of
+ <TT>`/usr/local'</TT>.
+ </DL>
+
+
+ <P>
+ It may be convenient for users to have @command{configure} guess the
+ installation prefix from the location of a related program that they
+ have already installed. If you wish to do that, you can call
+ <CODE>AC_PREFIX_PROGRAM</CODE>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PREFIX_PROGRAM</B> <I>(<VAR>program</VAR>)</I>
+ <DD><A NAME="IDX154"></A>
+ <A NAME="IDX155"></A>
+ If the user did not specify an installation prefix (using the
+ @option{--prefix} option), guess a value for it by looking for
+ <VAR>program</VAR> in <CODE>PATH</CODE>, the way the shell does. If <VAR>program</VAR>
+ is found, set the prefix to the parent of the directory containing
+ <VAR>program</VAR>; otherwise leave the prefix specified in
+ <TT>`Makefile.in'</TT> unchanged. For example, if <VAR>program</VAR> is
+ <CODE>gcc</CODE> and the <CODE>PATH</CODE> contains <TT>`/usr/local/gnu/bin/gcc'</TT>,
+ set the prefix to <TT>`/usr/local/gnu'</TT>.
+ </DL>
+
+
+
+
+ <H1><A NAME="SEC35" HREF="autoconf_toc.html#TOC35">Existing Tests</A></H1>
+
+ <P>
+ These macros test for particular system features that packages might
+ need or want to use. If you need to test for a kind of feature that
+ none of these macros check for, you can probably do it by calling
+ primitive test macros with appropriate arguments (see section <A HREF="autoconf.html#SEC68">Writing Tests</A>).
+
+
+ <P>
+ These tests print messages telling the user which feature they're
+ checking for, and what they find. They cache their results for future
+ @command{configure} runs (see section <A HREF="autoconf.html#SEC82">Caching Results</A>).
+
+
+ <P>
+ Some of these macros set output variables. See section <A HREF="autoconf.html#SEC22">Substitutions in Makefiles</A>, for how to get their values. The phrase "define
+ <VAR>name</VAR>" is used below as a shorthand to mean "define C
+ preprocessor symbol <VAR>name</VAR> to the value 1". See section <A HREF="autoconf.html#SEC80">Defining C Preprocessor Symbols</A>, for how to get those symbol definitions into your program.
+
+
+
+
+ <H2><A NAME="SEC36" HREF="autoconf_toc.html#TOC36">Common Behavior</A></H2>
+
+ <P>
+ Much effort has been expended to make Autoconf easy to learn. The most
+ obvious way to reach this goal is simply to enforce standard interfaces
+ and behaviors, avoiding exceptions as much as possible. Because of
+ history and inertia, unfortunately, there are still too many exceptions
+ in Autoconf; nevertheless, this section describes some of the common
+ rules.
+
+
+
+
+ <H3><A NAME="SEC37" HREF="autoconf_toc.html#TOC37">Standard Symbols</A></H3>
+
+ <P>
+ All the generic macros that <CODE>AC_DEFINE</CODE> a symbol as a result of
+ their test transform their <VAR>argument</VAR>s to a standard alphabet.
+ First, <VAR>argument</VAR> is converted to upper case and any asterisks
+ (<SAMP>`*'</SAMP>) are each converted to <SAMP>`P'</SAMP>. Any remaining characters
+ that are not alphanumeric are converted to underscores.
+
+
+ <P>
+ For instance,
+
+
+
+ <PRE>
+ AC_CHECK_TYPES(struct $Expensive*)
+ </PRE>
+
+ <P>
+ will define the symbol <SAMP>`HAVE_STRUCT__EXPENSIVEP'</SAMP> if the check
+ succeeds.
+
+
+
+
+ <H3><A NAME="SEC38" HREF="autoconf_toc.html#TOC38">Default Includes</A></H3>
+ <P>
+ <A NAME="IDX156"></A>
+
+
+ <P>
+ Several tests depend upon a set of header files. Since these headers
+ are not universally available, tests actually have to provide a set of
+ protected includes, such as:
+
+
+
+ <PRE>
+ #if TIME_WITH_SYS_TIME
+ # include <sys/time.h>
+ # include <time.h>
+ #else
+ # if HAVE_SYS_TIME_H
+ # include <sys/time.h>
+ # else
+ # include <time.h>
+ # endif
+ #endif
+ </PRE>
+
+ <P>
+ Unless you know exactly what you are doing, you should avoid using
+ unconditional includes, and check the existence of the headers you
+ include beforehand (see section <A HREF="autoconf.html#SEC48">Header Files</A>).
+
+
+ <P>
+ Most generic macros provide the following default set of includes:
+
+
+
+ <PRE>
+ #include <stdio.h>
+ #if HAVE_SYS_TYPES_H
+ # include <sys/types.h>
+ #endif
+ #if HAVE_SYS_STAT_H
+ # include <sys/stat.h>
+ #endif
+ #if STDC_HEADERS
+ # include <stdlib.h>
+ # include <stddef.h>
+ #else
+ # if HAVE_STDLIB_H
+ # include <stdlib.h>
+ # endif
+ #endif
+ #if HAVE_STRING_H
+ # if !STDC_HEADERS && HAVE_MEMORY_H
+ # include <memory.h>
+ # endif
+ # include <string.h>
+ #endif
+ #if HAVE_STRINGS_H
+ # include <strings.h>
+ #endif
+ #if HAVE_INTTYPES_H
+ # include <inttypes.h>
+ #else
+ # if HAVE_STDINT_H
+ # include <stdint.h>
+ # endif
+ #endif
+ #if HAVE_UNISTD_H
+ # include <unistd.h>
+ #endif
+ </PRE>
+
+ <P>
+ If the default includes are used, then Autoconf will automatically check
+ for the presence of these headers and their compatibility, i.e., you
+ don't need to run <CODE>AC_HEADERS_STDC</CODE>, nor check for <TT>`stdlib.h'</TT>
+ etc.
+
+
+ <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> will be defined, but
+ <CODE>HAVE_STRINGS_H</CODE> won't.
+
+
+
+
+ <H2><A NAME="SEC39" HREF="autoconf_toc.html#TOC39">Alternative Programs</A></H2>
+ <P>
+ <A NAME="IDX157"></A>
+
+
+ <P>
+ These macros check for the presence or behavior of particular programs.
+ They are used to choose between several alternative programs and to
+ decide what to do once one has been chosen. If there is no macro
+ specifically defined to check for a program you need, and you don't need
+ to check for any special properties of it, then you can use one of the
+ general program-check macros.
+
+
+
+
+ <H3><A NAME="SEC40" HREF="autoconf_toc.html#TOC40">Particular Program Checks</A></H3>
+
+ <P>
+ These macros check for particular programs--whether they exist, and
+ in some cases whether they support certain features.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_AWK</B>
+ <DD><A NAME="IDX158"></A>
+ <A NAME="IDX159"></A>
+ <A NAME="IDX160"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_INSTALL</B>
+ <DD><A NAME="IDX161"></A>
+ <A NAME="IDX162"></A>
+ <A NAME="IDX163"></A>
+ <A NAME="IDX164"></A>
+ <A NAME="IDX165"></A>
+ <A NAME="IDX166"></A>
+ Set output variable <CODE>INSTALL</CODE> to the path of a BSD compatible
+ <CODE>install</CODE> program, if one is found in the current <CODE>PATH</CODE>.
+ 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> (see section <A HREF="autoconf.html#SEC19">Outputting Files</A>). 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} -m 644'</SAMP>.
+
+
+ <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 <TT>`Makefile'</TT>.
+
+
+ <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, or
+ @command{configure} will produce 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>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_LEX</B>
+ <DD><A NAME="IDX167"></A>
+ <A NAME="IDX168"></A>
+ <A NAME="IDX169"></A>
+ <A NAME="IDX170"></A>
+ <A NAME="IDX171"></A>
+ <A NAME="IDX172"></A>
+ If <CODE>flex</CODE> is found, set output variable <CODE>LEX</CODE> to <SAMP>`flex'</SAMP>
+ and <CODE>LEXLIB</CODE> to @option{-lfl}, if that library is in a standard
+ place. Otherwise set <CODE>LEX</CODE> to <SAMP>`lex'</SAMP> and <CODE>LEXLIB</CODE> to
+ @option{-ll}.
+
+
+ <P>
+ Define <CODE>YYTEXT_POINTER</CODE> if <CODE>yytext</CODE> is a <SAMP>`char *'</SAMP> instead
+ of a <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>
+ 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:
+
+
+
+ <PRE>
+ AC_PROG_LEX
+ if test "$LEX" != flex; then
+ LEX="$SHELL $missing_dir/missing flex"
+ AC_SUBST(LEX_OUTPUT_ROOT, lex.yy)
+ AC_SUBST(LEXLIB, '')
+ fi
+ </PRE>
+
+ <P>
+ The shell script @command{missing} can be found in the Automake
+ distribution.
+
+
+ <P>
+ To ensure backward compatibility, Automake's <CODE>AM_PROG_LEX</CODE> invokes
+ (indirectly) this macro twice, which will cause 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_LN_S</B>
+ <DD><A NAME="IDX173"></A>
+ <A NAME="IDX174"></A>
+ <A NAME="IDX175"></A>
+ 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>
+ If you make a link 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>
+ In other words, it does not work to do:
+
+ <PRE>
+ $(LN_S) foo /x/bar
+ </PRE>
+
+ <P>
+ Instead, do:
+
+
+
+ <PRE>
+ (cd /x && $(LN_S) foo bar)
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_RANLIB</B>
+ <DD><A NAME="IDX176"></A>
+ <A NAME="IDX177"></A>
+ <A NAME="IDX178"></A>
+ Set output variable <CODE>RANLIB</CODE> to <SAMP>`ranlib'</SAMP> if <CODE>ranlib</CODE>
+ is found, and otherwise to <SAMP>`:'</SAMP> (do nothing).
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_YACC</B>
+ <DD><A NAME="IDX179"></A>
+ <A NAME="IDX180"></A>
+ <A NAME="IDX181"></A>
+ 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>.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC41" HREF="autoconf_toc.html#TOC41">Generic Program and File Checks</A></H3>
+
+ <P>
+ These macros are used to find programs not covered by the "particular"
+ test macros. If you need to check the behavior of a program as well as
+ find out whether it is present, you have to write your own test for it
+ (see section <A HREF="autoconf.html#SEC68">Writing Tests</A>). By default, these macros use the environment
+ variable <CODE>PATH</CODE>. If you need to check for a program that might not
+ be in the user's <CODE>PATH</CODE>, you can pass a modified path to use
+ instead, like this:
+
+
+
+ <PRE>
+ AC_PATH_PROG([INETD], [inetd], [/usr/libexec/inetd],
+ [$PATH:/usr/libexec:/usr/sbin:/usr/etc:etc])
+ </PRE>
+
+ <P>
+ You are strongly encouraged to declare the <VAR>variable</VAR> passed to
+ <CODE>AC_CHECK_PROG</CODE> etc. as precious, See section <A HREF="autoconf.html#SEC81">Setting Output Variables</A>,
+ <CODE>AC_ARG_VAR</CODE>, for more details.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_PROG</B> <I>(<VAR>variable</VAR>, <VAR>prog-to-check-for</VAR>, <VAR>value-if-found</VAR>, @ovar{value-if-not-found}, @ovar{path}, @ovar{reject})</I>
+ <DD><A NAME="IDX182"></A>
+ <A NAME="IDX183"></A>
+ Check whether program <VAR>prog-to-check-for</VAR> exists in <CODE>PATH</CODE>. 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_PROGS</B> <I>(<VAR>variable</VAR>, <VAR>progs-to-check-for</VAR>, @ovar{value-if-not-found}, @ovar{path})</I>
+ <DD><A NAME="IDX184"></A>
+ <A NAME="IDX185"></A>
+ Check for each program in the whitespace-separated list
+ <VAR>progs-to-check-for</VAR> exists on the <CODE>PATH</CODE>. If it 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_TOOL</B> <I>(<VAR>variable</VAR>, <VAR>prog-to-check-for</VAR>, @ovar{value-if-not-found}, @ovar{path})</I>
+ <DD><A NAME="IDX186"></A>
+ <A NAME="IDX187"></A>
+ Like <CODE>AC_CHECK_PROG</CODE>, but first looks for <VAR>prog-to-check-for</VAR>
+ with a prefix of the host type as determined by
+ <CODE>AC_CANONICAL_HOST</CODE>, followed by a dash (see section <A HREF="autoconf.html#SEC123">Getting the Canonical System Type</A>).
+ For example, if the user runs <SAMP>`configure --host=i386-gnu'</SAMP>, then
+ this call:
+
+ <PRE>
+ AC_CHECK_TOOL(RANLIB, ranlib, :)
+ </PRE>
+
+ <P>
+ sets <CODE>RANLIB</CODE> to <TT>`i386-gnu-ranlib'</TT> if that program exists in
+ <CODE>PATH</CODE>, or otherwise to <SAMP>`ranlib'</SAMP> if that program exists in
+ <CODE>PATH</CODE>, or to <SAMP>`:'</SAMP> if neither program exists.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_TOOLS</B> <I>(<VAR>variable</VAR>, <VAR>progs-to-check-for</VAR>, @ovar{value-if-not-found}, @ovar{path})</I>
+ <DD><A NAME="IDX188"></A>
+ <A NAME="IDX189"></A>
+ 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
+ (see section <A HREF="autoconf.html#SEC123">Getting the Canonical System Type</A>). 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PATH_PROG</B> <I>(<VAR>variable</VAR>, <VAR>prog-to-check-for</VAR>, @ovar{value-if-not-found}, @ovar{path})</I>
+ <DD><A NAME="IDX190"></A>
+ <A NAME="IDX191"></A>
+ Like <CODE>AC_CHECK_PROG</CODE>, but set <VAR>variable</VAR> to the entire
+ path of <VAR>prog-to-check-for</VAR> if found.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PATH_PROGS</B> <I>(<VAR>variable</VAR>, <VAR>progs-to-check-for</VAR>, @ovar{value-if-not-found}, @ovar{path})</I>
+ <DD><A NAME="IDX192"></A>
+ <A NAME="IDX193"></A>
+ Like <CODE>AC_CHECK_PROGS</CODE>, but if any of <VAR>progs-to-check-for</VAR>
+ are found, set <VAR>variable</VAR> to the entire path of the program
+ found.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PATH_TOOL</B> <I>(<VAR>variable</VAR>, <VAR>prog-to-check-for</VAR>, @ovar{value-if-not-found}, @ovar{path})</I>
+ <DD><A NAME="IDX194"></A>
+ <A NAME="IDX195"></A>
+ Like <CODE>AC_CHECK_TOOL</CODE>, but set <VAR>variable</VAR> to the entire
+ path of the program if it is found.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC42" HREF="autoconf_toc.html#TOC42">Files</A></H2>
+ <P>
+ <A NAME="IDX196"></A>
+
+
+ <P>
+ You might also need to check for the existence of files. Before using
+ these macros, ask yourself whether a run time test might not be a better
+ solution. Be aware that, like most Autoconf macros, they test a feature
+ of the host machine, and therefore, they die when cross-compiling.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_FILE</B> <I>(<VAR>file</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX197"></A>
+ <A NAME="IDX198"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_FILES</B> <I>(<VAR>files</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX199"></A>
+ <A NAME="IDX200"></A>
+ Executes <CODE>AC_CHECK_FILE</CODE> once for each file listed in <VAR>files</VAR>.
+ Additionally, defines <SAMP>`HAVE_<VAR>file</VAR>'</SAMP> (see section <A HREF="autoconf.html#SEC37">Standard Symbols</A>)
+ for each file found.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC43" HREF="autoconf_toc.html#TOC43">Library Files</A></H2>
+ <P>
+ <A NAME="IDX201"></A>
+
+
+ <P>
+ The following macros check for the presence of certain C, C++ or Fortran
+ 77 library archive files.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_LIB</B> <I>(<VAR>library</VAR>, <VAR>function</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})</I>
+ <DD><A NAME="IDX202"></A>
+ <A NAME="IDX203"></A>
+ Depending on the current language(see section <A HREF="autoconf.html#SEC78">Language Choice</A>), try to
+ ensure that the C, C++, or Fortran 77 function <VAR>function</VAR> is
+ available by checking whether a test program can be linked with the
+ library <VAR>library</VAR> to get the function. <VAR>library</VAR> is the base
+ name of the library; e.g., to check for @option{-lmp}, use <SAMP>`mp'</SAMP> as
+ the <VAR>library</VAR> argument.
+
+
+ <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 will prepend @option{-l<VAR>library</VAR>} to
+ <CODE>LIBS</CODE> and define <SAMP>`HAVE_LIB<VAR>library</VAR>'</SAMP> (in all
+ capitals). This macro is intended to support building of <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. Some linkers are very sensitive to library ordering
+ so the order in which <CODE>LIBS</CODE> is generated is important to reliable
+ detection of libraries.
+
+
+ <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. @option{-lXt -lX11}. Otherwise, this macro will fail to detect
+ that <VAR>library</VAR> is present, because linking the test program will
+ always 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SEARCH_LIBS</B> <I>(<VAR>function</VAR>, <VAR>search-libs</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})</I>
+ <DD><A NAME="IDX204"></A>
+ <A NAME="IDX205"></A>
+ Search for a library defining <VAR>function</VAR> if it's not already
+ available. This equates to calling <CODE>AC_TRY_LINK_FUNC</CODE> first
+ with no libraries, then for each library listed in <VAR>search-libs</VAR>.
+
+
+ <P>
+ Add @option{-l<VAR>library</VAR>} 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>
+ 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. @option{-lXt -lX11}. Otherwise, this macro will fail to detect
+ that <VAR>function</VAR> is present, because linking the test program will
+ always fail with unresolved symbols.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC44" HREF="autoconf_toc.html#TOC44">Library Functions</A></H2>
+
+ <P>
+ The following macros check for particular C library functions.
+ If there is no macro specifically defined to check for a function you need,
+ and you don't need to check for any special properties of
+ it, then you can use one of the general function-check macros.
+
+
+
+
+ <H3><A NAME="SEC45" HREF="autoconf_toc.html#TOC45">Portability of C Functions</A></H3>
+
+ <P>
+ Most usual functions can either be missing, or be buggy, or be limited
+ on some architectures. This section tries to make an inventory of these
+ portability issues. By definition, this list will always require
+ additions. Please help us keeping it as complete as possible.
+
+
+ <DL COMPACT>
+
+ <DT><CODE>snprintf</CODE>
+ <DD>
+ <A NAME="IDX206"></A>
+ <A NAME="IDX207"></A>
+ The ISO C99 standard says that if the output array isn't big enough and
+ if no other errors occur, <CODE>snprintf</CODE> and <CODE>vsnprintf</CODE> truncate
+ the output and return the number of bytes that ought to have been
+ produced. Some older systems return the truncated length (e.g., GNU C
+ Library 2.0.x or IRIX 6.5), some a negative value (e.g., earlier GNU C
+ Library versions), and some the buffer length without truncation (e.g.,
+ 32-bit Solaris 7). Also, some buggy older systems ignore the length and
+ overrun the buffer (e.g., 64-bit Solaris 7).
+
+ <DT><CODE>sprintf</CODE>
+ <DD>
+ <A NAME="IDX208"></A>
+ <A NAME="IDX209"></A>
+ The ISO C standard says <CODE>sprintf</CODE> and <CODE>vsprintf</CODE> return the
+ number of bytes written, but on some old systems (SunOS 4 for
+ instance) they return the buffer pointer instead.
+
+ <DT><CODE>sscanf</CODE>
+ <DD>
+ <A NAME="IDX210"></A>
+ On various old systems, e.g. HP-UX 9, <CODE>sscanf</CODE> requires that its
+ input string is writable (though it doesn't actually change it). This
+ can be a problem when using @command{gcc} since it normally puts
+ constant strings in read-only memory
+ (see section `Incompatibilities' in <CITE>Using and Porting the GNU Compiler Collection</CITE>). Apparently in some cases even
+ having format strings read-only can be a problem.
+
+ <DT><CODE>strnlen</CODE>
+ <DD>
+ <A NAME="IDX211"></A>
+ AIX 4.3 provides a broken version which produces funny results:
+
+
+ <PRE>
+ strnlen ("foobar", 0) = 0
+ strnlen ("foobar", 1) = 3
+ strnlen ("foobar", 2) = 2
+ strnlen ("foobar", 3) = 1
+ strnlen ("foobar", 4) = 0
+ strnlen ("foobar", 5) = 6
+ strnlen ("foobar", 6) = 6
+ strnlen ("foobar", 7) = 6
+ strnlen ("foobar", 8) = 6
+ strnlen ("foobar", 9) = 6
+ </PRE>
+
+ <DT><CODE>unlink</CODE>
+ <DD>
+ <A NAME="IDX212"></A>
+ The POSIX spec says that <CODE>unlink</CODE> causes the given files to be
+ removed only after there are no more open file handles for it. Not all
+ OS's support this behaviour though. So even on systems that provide
+ <CODE>unlink</CODE>, you cannot portably assume it is OK to call it on files
+ that are open. For example, on Windows 9x and ME, such a call would fail;
+ on DOS it could even lead to file system corruption, as the file might end
+ up being written to after the OS has removed it.
+
+ <DT><CODE>va_copy</CODE>
+ <DD>
+ <A NAME="IDX213"></A>
+ The ISO C99 standard provides <CODE>va_copy</CODE> for copying
+ <CODE>va_list</CODE> variables. It may be available in older environments
+ too, though possibly as <CODE>__va_copy</CODE> (eg. @command{gcc} in strict
+ C89 mode). These can be tested with <CODE>#ifdef</CODE>. A fallback to
+ <CODE>memcpy (&dst, &src, sizeof(va_list))</CODE> will give maximum
+ portability.
+
+ <DT><CODE>va_list</CODE>
+ <DD>
+ <A NAME="IDX214"></A>
+ <CODE>va_list</CODE> is not necessarily just a pointer. It can be a
+ <CODE>struct</CODE> (eg. @command{gcc} on Alpha), which means <CODE>NULL</CODE> is
+ not portable. Or it can be an array (eg. @command{gcc} in some
+ PowerPC configurations), which means as a function parameter it can be
+ effectively call-by-reference and library routines might modify the
+ value back in the caller (eg. <CODE>vsnprintf</CODE> in the GNU C Library
+ 2.1).
+
+ <DT>Signed <CODE>>></CODE>
+ <DD>
+ Normally the C <CODE>>></CODE> right shift of a signed type replicates the
+ high bit, giving a so-called "arithmetic" shift. But care should be
+ taken since the ISO C standard doesn't require that behaviour. On those
+ few processors without a native arithmetic shift (for instance Cray
+ vector systems) zero bits may be shifted in, the same as a shift of an
+ unsigned type.
+ </DL>
+
+
+
+ <H3><A NAME="SEC46" HREF="autoconf_toc.html#TOC46">Particular Function Checks</A></H3>
+ <P>
+ <A NAME="IDX215"></A>
+
+
+ <P>
+ These macros check for particular C functions--whether they exist, and
+ in some cases how they respond when given certain arguments.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_ALLOCA</B>
+ <DD><A NAME="IDX216"></A>
+ <A NAME="IDX217"></A>
+ <A NAME="IDX218"></A>
+ <A NAME="IDX219"></A>
+ <A NAME="IDX220"></A>
+ <A NAME="IDX221"></A>
+ 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>
+ 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>`alloca.o'</SAMP> 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>.
+
+
+ <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>
+ Source files that use <CODE>alloca</CODE> should start with a piece of code
+ like the following, to declare it properly. In some versions of AIX,
+ the declaration of <CODE>alloca</CODE> must precede everything else except for
+ comments and preprocessor directives. The <CODE>#pragma</CODE> directive is
+ indented so that pre-ANSI C compilers will ignore it, rather than
+ choke on it.
+
+
+
+ <PRE>
+ /* AIX requires this to be the first thing in the file. */
+ #ifndef __GNUC__
+ # if HAVE_ALLOCA_H
+ # include <alloca.h>
+ # else
+ # ifdef _AIX
+ #pragma alloca
+ # else
+ # ifndef alloca /* predefined by HP cc +Olibcalls */
+ char *alloca ();
+ # endif
+ # endif
+ # endif
+ #endif
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_CHOWN</B>
+ <DD><A NAME="IDX222"></A>
+ <A NAME="IDX223"></A>
+ <A NAME="IDX224"></A>
+ If the <CODE>chown</CODE> function is available and works (in particular, it
+ should accept @option{-1} for <CODE>uid</CODE> and <CODE>gid</CODE>), define
+ <CODE>HAVE_CHOWN</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_CLOSEDIR_VOID</B>
+ <DD><A NAME="IDX225"></A>
+ <A NAME="IDX226"></A>
+ <A NAME="IDX227"></A>
+ <A NAME="IDX228"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_ERROR_AT_LINE</B>
+ <DD><A NAME="IDX229"></A>
+ <A NAME="IDX230"></A>
+ <A NAME="IDX231"></A>
+ If the <CODE>error_at_line</CODE> function is not found, require an
+ <CODE>AC_LIBOBJ</CODE> replacement of <SAMP>`error'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_FNMATCH</B>
+ <DD><A NAME="IDX232"></A>
+ <A NAME="IDX233"></A>
+ <A NAME="IDX234"></A>
+ If the <CODE>fnmatch</CODE> function is available and works (unlike the one on
+ Solaris 2.4), define <CODE>HAVE_FNMATCH</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_FORK</B>
+ <DD><A NAME="IDX235"></A>
+ <A NAME="IDX236"></A>
+ <A NAME="IDX237"></A>
+ <A NAME="IDX238"></A>
+ <A NAME="IDX239"></A>
+ <A NAME="IDX240"></A>
+ <A NAME="IDX241"></A>
+ <A NAME="IDX242"></A>
+ 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>
+ 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 @command{autoconf}. 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>
+ Since this macro defines <CODE>vfork</CODE> only for backward compatibility with
+ previous versions of @command{autoconf} you're encouraged to define it
+ yourself in new code:
+
+ <PRE>
+ #if !HAVE_WORKING_VFORK
+ # define vfork fork
+ #endif
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_FSEEKO</B>
+ <DD><A NAME="IDX243"></A>
+ <A NAME="IDX244"></A>
+ <A NAME="IDX245"></A>
+ <A NAME="IDX246"></A>
+ If the <CODE>fseeko</CODE> function is available, define <CODE>HAVE_FSEEKO</CODE>.
+ Define <CODE>_LARGEFILE_SOURCE</CODE> if necessary.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_GETGROUPS</B>
+ <DD><A NAME="IDX247"></A>
+ <A NAME="IDX248"></A>
+ <A NAME="IDX249"></A>
+ <A NAME="IDX250"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_GETLOADAVG</B>
+ <DD><A NAME="IDX251"></A>
+ <A NAME="IDX252"></A>
+ <A NAME="IDX253"></A>
+ <A NAME="IDX254"></A>
+ <A NAME="IDX255"></A>
+ <A NAME="IDX256"></A>
+ <A NAME="IDX257"></A>
+ <A NAME="IDX258"></A>
+ <A NAME="IDX259"></A>
+ <A NAME="IDX260"></A>
+ <A NAME="IDX261"></A>
+ <A NAME="IDX262"></A>
+ <A NAME="IDX263"></A>
+ <A NAME="IDX264"></A>
+ <A NAME="IDX265"></A>
+ <A NAME="IDX266"></A>
+ Check how to get the system load averages. If the system has the
+ <CODE>getloadavg</CODE> function, define <CODE>HAVE_GETLOADAVG</CODE>, and set
+ <CODE>GETLOADAVG_LIBS</CODE> to any libraries needed to get that function.
+ Also add <CODE>GETLOADAVG_LIBS</CODE> to <CODE>LIBS</CODE>.
+
+
+ <P>
+ Otherwise, require an <CODE>AC_LIBOBJ</CODE> replacement (<TT>`getloadavg.c'</TT>)
+ of <SAMP>`getloadavg'</SAMP>, and possibly define several other C preprocessor
+ macros and output variables:
+
+
+
+ <OL>
+ <LI>
+
+ Define <CODE>C_GETLOADAVG</CODE>.
+
+ <LI>
+
+ Define <CODE>SVR4</CODE>, <CODE>DGUX</CODE>, <CODE>UMAX</CODE>, or <CODE>UMAX4_3</CODE> if on
+ those systems.
+
+ <LI>
+
+ If <TT>`nlist.h'</TT> is found, define <CODE>NLIST_STRUCT</CODE>.
+
+ <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.
+
+ <LI>
+
+ Programs may need to be installed setgid (or setuid) 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>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_GETMNTENT</B>
+ <DD><A NAME="IDX267"></A>
+ <A NAME="IDX268"></A>
+ <A NAME="IDX269"></A>
+ <A NAME="IDX270"></A>
+ Check for <CODE>getmntent</CODE> in the <TT>`sun'</TT>, <TT>`seq'</TT>, and <TT>`gen'</TT>
+ libraries, for Irix 4, PTX, and Unixware, respectively. Then, if
+ <CODE>getmntent</CODE> is available, define <CODE>HAVE_GETMNTENT</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_GETPGRP</B>
+ <DD><A NAME="IDX271"></A>
+ <A NAME="IDX272"></A>
+ <A NAME="IDX273"></A>
+ <A NAME="IDX274"></A>
+ <A NAME="IDX275"></A>
+ Define <CODE>GETPGRP_VOID</CODE> if it is an error to pass 0 to
+ <CODE>getpgrp</CODE>; this is the POSIX.1 behavior. On older BSD
+ systems, you must pass 0 to <CODE>getpgrp</CODE>, as it takes an argument and
+ behaves like POSIX.1's <CODE>getpgid</CODE>.
+
+
+
+ <PRE>
+ #if GETPGRP_VOID
+ pid = getpgrp ();
+ #else
+ pid = getpgrp (0);
+ #endif
+ </PRE>
+
+ <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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK</B>
+ <DD><A NAME="IDX276"></A>
+ <A NAME="IDX277"></A>
+ <A NAME="IDX278"></A>
+ <A NAME="IDX279"></A>
+ 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>
+ It is safe to assume that if <CODE>lstat</CODE> incorrectly ignores
+ trailing slashes, then other symbolic-link-aware functions like
+ <CODE>unlink</CODE> and <CODE>unlink</CODE> also incorrectly ignore trailing slashes.
+
+
+ <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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_MALLOC</B>
+ <DD><A NAME="IDX280"></A>
+ <A NAME="IDX281"></A>
+ <A NAME="IDX282"></A>
+ If the <CODE>malloc</CODE> works correctly (<SAMP>`malloc (0)'</SAMP> returns a valid
+ pointer), define <CODE>HAVE_MALLOC</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_MEMCMP</B>
+ <DD><A NAME="IDX283"></A>
+ <A NAME="IDX284"></A>
+ <A NAME="IDX285"></A>
+ <A NAME="IDX286"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_MKTIME</B>
+ <DD><A NAME="IDX287"></A>
+ <A NAME="IDX288"></A>
+ <A NAME="IDX289"></A>
+ <A NAME="IDX290"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_MMAP</B>
+ <DD><A NAME="IDX291"></A>
+ <A NAME="IDX292"></A>
+ <A NAME="IDX293"></A>
+ <A NAME="IDX294"></A>
+ If the <CODE>mmap</CODE> function exists and works correctly, define
+ <CODE>HAVE_MMAP</CODE>. Only checks private fixed mapping of already-mapped
+ memory.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_OBSTACK</B>
+ <DD><A NAME="IDX295"></A>
+ <A NAME="IDX296"></A>
+ <A NAME="IDX297"></A>
+ <A NAME="IDX298"></A>
+ If the obstacks are found, define <CODE>HAVE_OBSTACK</CODE>, else require an
+ <CODE>AC_LIBOBJ</CODE> replacement for <SAMP>`obstack'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_SELECT_ARGTYPES</B>
+ <DD><A NAME="IDX299"></A>
+ <A NAME="IDX300"></A>
+ <A NAME="IDX301"></A>
+ <A NAME="IDX302"></A>
+ <A NAME="IDX303"></A>
+ <A NAME="IDX304"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_SETPGRP</B>
+ <DD><A NAME="IDX305"></A>
+ <A NAME="IDX306"></A>
+ <A NAME="IDX307"></A>
+ <A NAME="IDX308"></A>
+ If <CODE>setpgrp</CODE> takes no argument (the POSIX.1 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_STAT</B>
+ <DD><A NAME="IDX309"></A>
+ <DT><U>Macro:</U> <B>AC_FUNC_LSTAT</B>
+ <DD><A NAME="IDX310"></A>
+ <A NAME="IDX311"></A>
+ <A NAME="IDX312"></A>
+ <A NAME="IDX313"></A>
+ <A NAME="IDX314"></A>
+ <A NAME="IDX315"></A>
+ <A NAME="IDX316"></A>
+ Determine whether <CODE>stat</CODE> or <CODE>lstat</CODE> have the bug that it
+ succeeds when given the zero-length file name 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>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_SETVBUF_REVERSED</B>
+ <DD><A NAME="IDX317"></A>
+ <A NAME="IDX318"></A>
+ <A NAME="IDX319"></A>
+ <A NAME="IDX320"></A>
+ If <CODE>setvbuf</CODE> takes the buffering type as its second argument and
+ the buffer pointer as the third, instead of the other way around, define
+ <CODE>SETVBUF_REVERSED</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_STRCOLL</B>
+ <DD><A NAME="IDX321"></A>
+ <A NAME="IDX322"></A>
+ <A NAME="IDX323"></A>
+ <A NAME="IDX324"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_STRTOD</B>
+ <DD><A NAME="IDX325"></A>
+ <A NAME="IDX326"></A>
+ <A NAME="IDX327"></A>
+ <A NAME="IDX328"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_STRERROR_R</B>
+ <DD><A NAME="IDX329"></A>
+ <A NAME="IDX330"></A>
+ <A NAME="IDX331"></A>
+ <A NAME="IDX332"></A>
+ <A NAME="IDX333"></A>
+ <A NAME="IDX334"></A>
+ 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-200X 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_STRFTIME</B>
+ <DD><A NAME="IDX335"></A>
+ <A NAME="IDX336"></A>
+ <A NAME="IDX337"></A>
+ <A NAME="IDX338"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_STRNLEN</B>
+ <DD><A NAME="IDX339"></A>
+ <A NAME="IDX340"></A>
+ <A NAME="IDX341"></A>
+ <A NAME="IDX342"></A>
+ Check for a working <CODE>strnlen</CODE>, and ask for its replacement. Some
+ architectures are know to provide broken versions of <CODE>strnlen</CODE>, such
+ as AIX 4.3.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_UTIME_NULL</B>
+ <DD><A NAME="IDX343"></A>
+ <A NAME="IDX344"></A>
+ <A NAME="IDX345"></A>
+ <A NAME="IDX346"></A>
+ If <SAMP>`utime(<VAR>file</VAR>, NULL)'</SAMP> sets <VAR>file</VAR>'s timestamp to
+ the present, define <CODE>HAVE_UTIME_NULL</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_VPRINTF</B>
+ <DD><A NAME="IDX347"></A>
+ <A NAME="IDX348"></A>
+ <A NAME="IDX349"></A>
+ <A NAME="IDX350"></A>
+ <A NAME="IDX351"></A>
+ 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.)
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC47" HREF="autoconf_toc.html#TOC47">Generic Function Checks</A></H3>
+
+ <P>
+ These macros are used to find functions not covered by the "particular"
+ test macros. If the functions might be in libraries other than the
+ default C library, first call <CODE>AC_CHECK_LIB</CODE> for those libraries.
+ If you need to check the behavior of a function as well as find out
+ whether it is present, you have to write your own test for
+ it (see section <A HREF="autoconf.html#SEC68">Writing Tests</A>).
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_FUNC</B> <I>(<VAR>function</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX352"></A>
+ <A NAME="IDX353"></A>
+ 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++. (see section <A HREF="autoconf.html#SEC78">Language Choice</A>, for more information
+ about selecting the language for checks.)
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_FUNCS</B> <I>(<VAR>function</VAR>..., @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX354"></A>
+ <A NAME="IDX355"></A>
+ <A NAME="IDX356"></A>
+ For each <VAR>function</VAR> in the whitespace-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.
+ </DL>
+
+
+ <P>
+ Autoconf follows a philosophy that was formed over the years by those
+ who have struggled for portability: isolate the portability issues in
+ specific files, and then program as if you were in a POSIX
+ environment. Some functions may be missing or unfixable, and your
+ package must be ready to replace them.
+
+
+ <P>
+ Use the first three of the following macros to specify a function to be
+ replaced, and the last one (<CODE>AC_REPLACE_FUNCS</CODE>) to check for and
+ replace the function if needed.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LIBOBJ</B> <I>(<VAR>function</VAR>)</I>
+ <DD><A NAME="IDX357"></A>
+ <A NAME="IDX358"></A>
+ <A NAME="IDX359"></A>
+ 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>
+ Technically, it adds <SAMP>`<VAR>function</VAR>.$ac_objext'</SAMP> to the output
+ variable <CODE>LIBOBJS</CODE> 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LIBSOURCE</B> <I>(<VAR>file</VAR>)</I>
+ <DD><A NAME="IDX360"></A>
+ <A NAME="IDX361"></A>
+ 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>
+ 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:
+
+
+
+ <PRE>
+ AC_LIBSOURCE(foo.c)
+ AC_LIBSOURCE(bar.c)
+ AC_LIBOBJ($foo_or_bar)
+ </PRE>
+
+ <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>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LIBSOURCES</B> <I>(<VAR>files</VAR>)</I>
+ <DD><A NAME="IDX362"></A>
+ <A NAME="IDX363"></A>
+ 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:
+
+
+
+ <PRE>
+ AC_LIBSOURCES([foo.c, bar.c])
+ AC_LIBOBJ($foo_or_bar)
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_REPLACE_FUNCS</B> <I>(<VAR>function</VAR>...)</I>
+ <DD><A NAME="IDX364"></A>
+ <A NAME="IDX365"></A>
+ <A NAME="IDX366"></A>
+ 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>`#if !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.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC48" HREF="autoconf_toc.html#TOC48">Header Files</A></H2>
+ <P>
+ <A NAME="IDX367"></A>
+
+
+ <P>
+ The following macros check for the presence of certain C header files.
+ If there is no macro specifically defined to check for a header file you need,
+ and you don't need to check for any special properties of
+ it, then you can use one of the general header-file check macros.
+
+
+
+
+ <H3><A NAME="SEC49" HREF="autoconf_toc.html#TOC49">Particular Header Checks</A></H3>
+
+ <P>
+ These macros check for particular system header files--whether they
+ exist, and in some cases whether they declare certain symbols.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_DIRENT</B>
+ <DD><A NAME="IDX368"></A>
+ <A NAME="IDX369"></A>
+ <A NAME="IDX370"></A>
+ <A NAME="IDX371"></A>
+ <A NAME="IDX372"></A>
+ <A NAME="IDX373"></A>
+ Check for the following header files. For the first one that is
+ found and defines <SAMP>`DIR'</SAMP>, define the listed C preprocessor macro:
+
+
+ <LI><TT>`dirent.h'</TT> </TD><TD> <CODE>HAVE_DIRENT_H</CODE>
+
+ <LI><TT>`sys/ndir.h'</TT> </TD><TD> <CODE>HAVE_SYS_NDIR_H</CODE>
+
+ <LI><TT>`sys/dir.h'</TT> </TD><TD> <CODE>HAVE_SYS_DIR_H</CODE>
+
+ <LI><TT>`ndir.h'</TT> </TD><TD> <CODE>HAVE_NDIR_H</CODE>
+
+ The directory-library declarations in your source code should look
+ something like the following:
+
+
+ <PRE>
+ #if HAVE_DIRENT_H
+ # include <dirent.h>
+ # define NAMLEN(dirent) strlen((dirent)->d_name)
+ #else
+ # define dirent direct
+ # define NAMLEN(dirent) (dirent)->d_namlen
+ # if HAVE_SYS_NDIR_H
+ # include <sys/ndir.h>
+ # endif
+ # if HAVE_SYS_DIR_H
+ # include <sys/dir.h>
+ # endif
+ # if HAVE_NDIR_H
+ # include <ndir.h>
+ # endif
+ #endif
+ </PRE>
+
+ 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.
+
+ This macro also checks for the SCO Xenix <TT>`dir'</TT> and <TT>`x'</TT> libraries.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_MAJOR</B>
+ <DD><A NAME="IDX374"></A>
+ <A NAME="IDX375"></A>
+ <A NAME="IDX376"></A>
+ <A NAME="IDX377"></A>
+ 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>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_STAT</B>
+ <DD><A NAME="IDX378"></A>
+ <A NAME="IDX379"></A>
+ <A NAME="IDX380"></A>
+ If the macros <CODE>S_ISDIR</CODE>, <CODE>S_ISREG</CODE> et al. 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.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_STDC</B>
+ <DD><A NAME="IDX381"></A>
+ <A NAME="IDX382"></A>
+ <A NAME="IDX383"></A>
+ Define <CODE>STDC_HEADERS</CODE> if the system has ANSI C header files.
+ 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 ANSI C 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 ANSI C requires.
+
+ Use <CODE>STDC_HEADERS</CODE> instead of <CODE>__STDC__</CODE> to determine whether
+ the system has ANSI-compliant header files (and probably C library
+ functions) because many systems that have GCC do not have ANSI C
+ header files.
+
+ On systems without ANSI C 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 systems contain
+ a mix of functions ANSI and BSD; some are mostly ANSI but
+ lack <SAMP>`memmove'</SAMP>; some define the BSD functions as macros in
+ <TT>`string.h'</TT> or <TT>`strings.h'</TT>; some have only the BSD
+ functions but <TT>`string.h'</TT>; some declare 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 has the ANSI versions of those then it probably has
+ most of the others. If you put the following in <TT>`configure.ac'</TT>:
+
+
+ <PRE>
+ AC_HEADER_STDC
+ AC_CHECK_FUNCS(strchr memcpy)
+ </PRE>
+
+ then, in your code, you can put declarations like this:
+
+
+ <PRE>
+ #if STDC_HEADERS
+ # include <string.h>
+ #else
+ # if !HAVE_STRCHR
+ # define strchr index
+ # define strrchr rindex
+ # endif
+ char *strchr (), *strrchr ();
+ # if !HAVE_MEMCPY
+ # define memcpy(d, s, n) bcopy ((s), (d), (n))
+ # define memmove(d, s, n) bcopy ((s), (d), (n))
+ # endif
+ #endif
+ </PRE>
+
+ 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 won't
+ suffice; 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>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_SYS_WAIT</B>
+ <DD><A NAME="IDX384"></A>
+ <A NAME="IDX385"></A>
+ <A NAME="IDX386"></A>
+ If <TT>`sys/wait.h'</TT> exists and is compatible with POSIX.1, 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.1 compatible, then instead of including it, define the
+ POSIX.1 macros with their usual interpretations. Here is an
+ example:
+
+
+ <PRE>
+ #include <sys/types.h>
+ #if HAVE_SYS_WAIT_H
+ # include <sys/wait.h>
+ #endif
+ #ifndef WEXITSTATUS
+ # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
+ #endif
+ #ifndef WIFEXITED
+ # define WIFEXITED(stat_val) (((stat_val) & 255) == 0)
+ #endif
+ </PRE>
+
+ </DL>
+
+ <A NAME="IDX387"></A>
+ <CODE>_POSIX_VERSION</CODE> is defined when <TT>`unistd.h'</TT> is included on
+ POSIX.1 systems. If there is no <TT>`unistd.h'</TT>, it is definitely
+ not a POSIX.1 system. However, some non-POSIX.1 systems do
+ have <TT>`unistd.h'</TT>.
+
+ The way to check if the system supports POSIX.1 is:
+
+
+ <PRE>
+ #if HAVE_UNISTD_H
+ # include <sys/types.h>
+ # include <unistd.h>
+ #endif
+
+ #ifdef _POSIX_VERSION
+ /* Code for POSIX.1 systems. */
+ #endif
+ </PRE>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_TIME</B>
+ <DD><A NAME="IDX388"></A>
+ <A NAME="IDX389"></A>
+ <A NAME="IDX390"></A>
+ 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 older systems,
+ <TT>`sys/time.h'</TT> includes <TT>`time.h'</TT>, but <TT>`time.h'</TT> is not
+ protected against multiple inclusion, so programs should not explicitly
+ include both files. This macro is useful in programs that use, for
+ example, <CODE>struct timeval</CODE> or <CODE>struct timezone</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>.
+
+
+ <PRE>
+ #if TIME_WITH_SYS_TIME
+ # include <sys/time.h>
+ # include <time.h>
+ #else
+ # if HAVE_SYS_TIME_H
+ # include <sys/time.h>
+ # else
+ # include <time.h>
+ # endif
+ #endif
+ </PRE>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_TIOCGWINSZ</B>
+ <DD><A NAME="IDX391"></A>
+ <A NAME="IDX392"></A>
+ <A NAME="IDX393"></A>
+ 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>.
+
+ Use:
+
+
+ <PRE>
+ #if HAVE_TERMIOS_H
+ # include <termios.h>
+ #endif
+
+ #if GWINSZ_IN_SYS_IOCTL
+ # include <sys/ioctl.h>
+ #endif
+ </PRE>
+
+ </DL>
+
+
+
+ <H3><A NAME="SEC50" HREF="autoconf_toc.html#TOC50">Generic Header Checks</A></H3>
+
+ <P>
+ These macros are used to find system header files not covered by the
+ "particular" test macros. If you need to check the contents of a header
+ as well as find out whether it is present, you have to write your own
+ test for it (see section <A HREF="autoconf.html#SEC68">Writing Tests</A>).
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_HEADER</B> <I>(<VAR>header-file</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX394"></A>
+ <A NAME="IDX395"></A>
+ If the system header file <VAR>header-file</VAR> is usable, 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>
+ The meaning of "usable" depends upon the content of <VAR>includes</VAR>:
+
+
+ <DL COMPACT>
+
+ <DT>if <VAR>includes</VAR> is empty
+ <DD>
+ check whether
+
+
+ <PRE>
+ <VAR>header-file</VAR>
+ </PRE>
+
+ can be <EM>preprocessed</EM> without error.
+
+ <DT>if <VAR>include</VAR> is set
+ <DD>
+ Check whether
+
+
+ <PRE>
+ <VAR>includes</VAR>
+ #include <<VAR>header-file</VAR>>
+ </PRE>
+
+ can be <EM>compiled</EM> without error. You may use
+ <CODE>AC_CHECK_HEADER</CODE> (and <CODE>AC_CHECK_HEADERS</CODE>) to check whether
+ two headers are compatible.
+ </DL>
+
+ <P>
+ You may pass any kind of dummy content for <VAR>includes</VAR>, such as a
+ single space, a comment, to check whether <VAR>header-file</VAR> compiles
+ with success.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_HEADERS</B> <I>(<VAR>header-file</VAR>..., @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX396"></A>
+ <A NAME="IDX397"></A>
+ <A NAME="IDX398"></A>
+ For each given system header file <VAR>header-file</VAR> in the
+ whitespace-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>
+ Be sure to read the documentation of <CODE>AC_CHECK_HEADER</CODE> to
+ understand the influence of <VAR>includes</VAR>.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC51" HREF="autoconf_toc.html#TOC51">Declarations</A></H2>
+ <P>
+ <A NAME="IDX399"></A>
+
+
+ <P>
+ The following macros check for the declaration of variables and
+ functions. If there is no macro specifically defined to check for a
+ symbol you need, then you can use the general macros (see section <A HREF="autoconf.html#SEC53">Generic Declaration Checks</A>) or, for more complex tests, you may use
+ <CODE>AC_TRY_COMPILE</CODE> (see section <A HREF="autoconf.html#SEC70">Examining Syntax</A>).
+
+
+
+
+ <H3><A NAME="SEC52" HREF="autoconf_toc.html#TOC52">Particular Declaration Checks</A></H3>
+
+ <P>
+ The following macros check for certain declarations.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_DECL_SYS_SIGLIST</B>
+ <DD><A NAME="IDX400"></A>
+ <A NAME="IDX401"></A>
+ <A NAME="IDX402"></A>
+ Define <CODE>SYS_SIGLIST_DECLARED</CODE> if the variable <CODE>sys_siglist</CODE>
+ is declared in a system header file, either <TT>`signal.h'</TT> or
+ <TT>`unistd.h'</TT>.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC53" HREF="autoconf_toc.html#TOC53">Generic Declaration Checks</A></H3>
+
+ <P>
+ These macros are used to find declarations not covered by the "particular"
+ test macros.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_DECL</B> <I>(<VAR>symbol</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX403"></A>
+ <A NAME="IDX404"></A>
+ If <VAR>symbol</VAR> (a function or a variable) 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>. If no
+ <VAR>includes</VAR> are specified, the default includes are used
+ (see section <A HREF="autoconf.html#SEC38">Default Includes</A>).
+
+
+ <P>
+ This macro actually tests whether it is valid to use <VAR>symbol</VAR> as an
+ r-value, not if it is really declared, because it is much safer to avoid
+ introducing extra declarations when they are not needed.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_DECLS</B> <I>(<VAR>symbols</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX405"></A>
+ <A NAME="IDX406"></A>
+ <A NAME="IDX407"></A>
+ 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, 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>
+ This macro uses an m4 list as first argument:
+
+ <PRE>
+ AC_CHECK_DECLS(strdup)
+ AC_CHECK_DECLS([strlen])
+ AC_CHECK_DECLS([malloc, realloc, calloc, free])
+ </PRE>
+
+ <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> just like any other result of Autoconf:
+
+
+
+ <PRE>
+ #if !HAVE_DECL_SYMBOL
+ extern char *symbol;
+ #endif
+ </PRE>
+
+ <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:
+
+
+
+ <PRE>
+ #if defined HAVE_DECL_MALLOC && !HAVE_DECL_MALLOC
+ char *malloc (size_t *s);
+ #endif
+ </PRE>
+
+ <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.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC54" HREF="autoconf_toc.html#TOC54">Structures</A></H2>
+ <P>
+ <A NAME="IDX408"></A>
+
+
+ <P>
+ The following macros check for the presence of certain members in C
+ structures. If there is no macro specifically defined to check for a
+ member you need, then you can use the general structure-member macro
+ (see section <A HREF="autoconf.html#SEC56">Generic Structure Checks</A>) or, for more complex tests, you may use
+ <CODE>AC_TRY_COMPILE</CODE> (see section <A HREF="autoconf.html#SEC70">Examining Syntax</A>).
+
+
+
+
+ <H3><A NAME="SEC55" HREF="autoconf_toc.html#TOC55">Particular Structure Checks</A></H3>
+
+ <P>
+ The following macros check for certain structures or structure members.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STRUCT_ST_BLKSIZE</B>
+ <DD><A NAME="IDX409"></A>
+ <A NAME="IDX410"></A>
+ <A NAME="IDX411"></A>
+ <A NAME="IDX412"></A>
+ 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
+
+
+
+ <PRE>
+ AC_CHECK_MEMBERS([struct stat.st_blksize])
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STRUCT_ST_BLOCKS</B>
+ <DD><A NAME="IDX413"></A>
+ <A NAME="IDX414"></A>
+ <A NAME="IDX415"></A>
+ <A NAME="IDX416"></A>
+ <A NAME="IDX417"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STRUCT_ST_RDEV</B>
+ <DD><A NAME="IDX418"></A>
+ <A NAME="IDX419"></A>
+ <A NAME="IDX420"></A>
+ <A NAME="IDX421"></A>
+ 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:
+
+ <PRE>
+ AC_CHECK_MEMBERS([struct stat.st_rdev])
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STRUCT_TM</B>
+ <DD><A NAME="IDX422"></A>
+ <A NAME="IDX423"></A>
+ <A NAME="IDX424"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STRUCT_TIMEZONE</B>
+ <DD><A NAME="IDX425"></A>
+ <A NAME="IDX426"></A>
+ <A NAME="IDX427"></A>
+ <A NAME="IDX428"></A>
+ 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>.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC56" HREF="autoconf_toc.html#TOC56">Generic Structure Checks</A></H3>
+
+ <P>
+ These macros are used to find structure members not covered by the
+ "particular" test macros.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_MEMBER</B> <I>(<VAR>aggregate</VAR>.<VAR>member</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX429"></A>
+ <A NAME="IDX430"></A>
+ 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
+ (see section <A HREF="autoconf.html#SEC38">Default Includes</A>).
+
+
+
+ <PRE>
+ AC_CHECK_MEMBER(struct passwd.pw_gecos,,
+ [AC_MSG_ERROR([We need `passwd.pw_gecos'!])],
+ [#include <pwd.h>])
+ </PRE>
+
+ <P>
+ You can use this macro for sub-members:
+
+
+
+ <PRE>
+ AC_CHECK_MEMBER(struct top.middle.bot)
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_MEMBERS</B> <I>(<VAR>members</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX431"></A>
+ <A NAME="IDX432"></A>
+ 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).
+
+
+ <P>
+ This macro uses m4 lists:
+
+ <PRE>
+ AC_CHECK_MEMBERS([struct stat.st_rdev, struct stat.st_blksize])
+ </PRE>
+
+ </DL>
+
+
+
+ <H2><A NAME="SEC57" HREF="autoconf_toc.html#TOC57">Types</A></H2>
+
+ <P>
+ The following macros check for C types, either builtin or typedefs. If
+ there is no macro specifically defined to check for a type you need, and
+ you don't need to check for any special properties of it, then you can
+ use a general type-check macro.
+
+
+
+
+ <H3><A NAME="SEC58" HREF="autoconf_toc.html#TOC58">Particular Type Checks</A></H3>
+
+ <P>
+ These macros check for particular C types in <TT>`sys/types.h'</TT>,
+ <TT>`stdlib.h'</TT> and others, if they exist.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TYPE_GETGROUPS</B>
+ <DD><A NAME="IDX433"></A>
+ <A NAME="IDX434"></A>
+ <A NAME="IDX435"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TYPE_MODE_T</B>
+ <DD><A NAME="IDX436"></A>
+ <A NAME="IDX437"></A>
+ <A NAME="IDX438"></A>
+ Equivalent to <SAMP>`AC_CHECK_TYPE(mode_t, int)'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TYPE_OFF_T</B>
+ <DD><A NAME="IDX439"></A>
+ <A NAME="IDX440"></A>
+ <A NAME="IDX441"></A>
+ Equivalent to <SAMP>`AC_CHECK_TYPE(off_t, long)'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TYPE_PID_T</B>
+ <DD><A NAME="IDX442"></A>
+ <A NAME="IDX443"></A>
+ <A NAME="IDX444"></A>
+ Equivalent to <SAMP>`AC_CHECK_TYPE(pid_t, int)'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TYPE_SIGNAL</B>
+ <DD><A NAME="IDX445"></A>
+ <A NAME="IDX446"></A>
+ <A NAME="IDX447"></A>
+ 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>.
+
+
+ <P>
+ Define signal handlers as returning type <CODE>RETSIGTYPE</CODE>:
+
+
+
+ <PRE>
+ RETSIGTYPE
+ hup_handler ()
+ {
+ ...
+ }
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TYPE_SIZE_T</B>
+ <DD><A NAME="IDX448"></A>
+ <A NAME="IDX449"></A>
+ <A NAME="IDX450"></A>
+ Equivalent to <SAMP>`AC_CHECK_TYPE(size_t, unsigned)'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TYPE_UID_T</B>
+ <DD><A NAME="IDX451"></A>
+ <A NAME="IDX452"></A>
+ <A NAME="IDX453"></A>
+ <A NAME="IDX454"></A>
+ If <CODE>uid_t</CODE> is not defined, define <CODE>uid_t</CODE> to be <CODE>int</CODE> and
+ <CODE>gid_t</CODE> to be <CODE>int</CODE>.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC59" HREF="autoconf_toc.html#TOC59">Generic Type Checks</A></H3>
+
+ <P>
+ These macros are used to check for types not covered by the "particular"
+ test macros.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_TYPE</B> <I>(<VAR>type</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX455"></A>
+ <A NAME="IDX456"></A>
+ Check whether <VAR>type</VAR> is defined. It may be a compiler builtin type
+ or defined by the <VAR>includes</VAR> (see section <A HREF="autoconf.html#SEC38">Default Includes</A>).
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_TYPES</B> <I>(<VAR>types</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX457"></A>
+ <A NAME="IDX458"></A>
+ For each <VAR>type</VAR> of the <VAR>types</VAR> that is defined, define
+ <CODE>HAVE_<VAR>type</VAR></CODE> (in all capitals). If no <VAR>includes</VAR> are
+ specified, the default includes are used (see section <A HREF="autoconf.html#SEC38">Default Includes</A>). 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>
+ This macro uses m4 lists:
+
+ <PRE>
+ AC_CHECK_TYPES(ptrdiff_t)
+ AC_CHECK_TYPES([unsigned long long, uintmax_t])
+ </PRE>
+
+ </DL>
+
+ <P>
+ Autoconf, up to 2.13, used to provide to another version of
+ <CODE>AC_CHECK_TYPE</CODE>, broken by design. In order to keep backward
+ compatibility, a simple heuristics, quite safe but not totally, is
+ implemented. In case of doubt, read the documentation of the former
+ <CODE>AC_CHECK_TYPE</CODE>, see section <A HREF="autoconf.html#SEC150">Obsolete Macros</A>.
+
+
+
+
+ <H2><A NAME="SEC60" HREF="autoconf_toc.html#TOC60">Compilers and Preprocessors</A></H2>
+
+ <P>
+ <A NAME="IDX459"></A>
+ All the tests for compilers (<CODE>AC_PROG_CC</CODE>, <CODE>AC_PROG_CXX</CODE>,
+ <CODE>AC_PROG_F77</CODE>) define the output variable <CODE>EXEEXT</CODE> based on
+ the output of the 1compiler, typically to the empty string if Unix and
+ <SAMP>`.exe'</SAMP> if Win32 or OS/2.
+
+
+ <P>
+ <A NAME="IDX460"></A>
+ They also define the output variable <CODE>OBJEXT</CODE> based on the
+ output of the compiler, after .c files have been excluded, typically
+ to <SAMP>`o'</SAMP> if Unix, <SAMP>`obj'</SAMP> if Win32.
+
+
+ <P>
+ If the compiler being used does not produce executables, they fail. If
+ the executables can't be run, and cross-compilation is not enabled, they
+ fail too. See section <A HREF="autoconf.html#SEC121">Manual Configuration</A>, for more on support for cross
+ compiling.
+
+
+
+
+ <H3><A NAME="SEC61" HREF="autoconf_toc.html#TOC61">Specific Compiler Characteristics</A></H3>
+
+ <P>
+ Some compilers exhibit different behaviors.
+
+
+ <DL COMPACT>
+
+ <DT>Static/Dynamic Expressions
+ <DD>
+ Autoconf relies on a trick to extract one bit of information from the C
+ compiler: using negative array sizes. For instance the following
+ excerpt of a C source demonstrates how to test whether <SAMP>`int'</SAMP>s are 4
+ bytes long:
+
+
+ <PRE>
+ int
+ main (void)
+ {
+ static int test_array [sizeof (int) == 4 ? 1 : -1];
+ test_array [0] = 0
+ return 0;
+ }
+ </PRE>
+
+ To our knowledge, there is a single compiler that does not support this
+ trick: the HP C compilers (the real one, not only the "bundled") on
+ HP-UX 11.00:
+
+
+ <PRE>
+ $ <KBD>cc -c -Ae +O2 +Onolimit conftest.c</KBD>
+ cc: "conftest.c": error 1879: Variable-length arrays cannot \
+ have static storage.
+ </PRE>
+
+ Autoconf works around this problem by casting <CODE>sizeof (int)</CODE> to
+ <CODE>long</CODE> before comparing it.
+ </DL>
+
+
+
+ <H3><A NAME="SEC62" HREF="autoconf_toc.html#TOC62">Generic Compiler Characteristics</A></H3>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_SIZEOF</B> <I>(<VAR>type</VAR>, @ovar{unused}, @dvar{includes, default-includes})</I>
+ <DD><A NAME="IDX461"></A>
+ <A NAME="IDX462"></A>
+ Define <CODE>SIZEOF_<VAR>type</VAR></CODE> (see section <A HREF="autoconf.html#SEC37">Standard Symbols</A>) to be the
+ size in bytes of <VAR>type</VAR>. If <SAMP>`type'</SAMP> is unknown, it gets a size
+ of 0. If no <VAR>includes</VAR> are specified, the default includes are used
+ (see section <A HREF="autoconf.html#SEC38">Default Includes</A>). If you provide <VAR>include</VAR>, make sure to
+ include <TT>`stdio.h'</TT> which is required for this macro to run.
+
+
+ <P>
+ This macro now works even when cross-compiling. The <VAR>unused</VAR>
+ argument was used when cross-compiling.
+
+
+ <P>
+ For example, the call
+
+
+
+ <PRE>
+ AC_CHECK_SIZEOF(int *)
+ </PRE>
+
+ <P>
+ defines <CODE>SIZEOF_INT_P</CODE> to be 8 on DEC Alpha AXP systems.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC63" HREF="autoconf_toc.html#TOC63">C Compiler Characteristics</A></H3>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_CC</B> <I>(@ovar{compiler-search-list})</I>
+ <DD><A NAME="IDX463"></A>
+ <A NAME="IDX464"></A>
+ <A NAME="IDX465"></A>
+ <A NAME="IDX466"></A>
+ 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>
+ This macro may, however, be invoked with an optional first argument
+ which, if specified, must be a space 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:
+
+
+
+ <PRE>
+ AC_PROG_CC(cl egcs gcc cc)
+ </PRE>
+
+ <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 @option{-g -O2} for the GNU C compiler (@option{-O2} on systems
+ where GCC does not accept @option{-g}), or @option{-g} for other compilers.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_CC_C_O</B>
+ <DD><A NAME="IDX467"></A>
+ <A NAME="IDX468"></A>
+ <A NAME="IDX469"></A>
+ If the C compiler does not accept the @option{-c} and @option{-o} 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_CC_STDC</B>
+ <DD><A NAME="IDX470"></A>
+ <A NAME="IDX471"></A>
+ <A NAME="IDX472"></A>
+ If the C compiler is not in ANSI C 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 C on some system or another. It
+ considers the compiler to be in ANSI C mode if it handles function
+ prototypes correctly.
+
+
+ <P>
+ If you use this macro, you should check after calling it whether the C
+ compiler has been set to accept ANSI C; if not, the shell variable
+ <CODE>ac_cv_prog_cc_stdc</CODE> is set to <SAMP>`no'</SAMP>. If you wrote your source
+ code in ANSI C, you can make an un-ANSIfied copy of it by
+ using the program <CODE>ansi2knr</CODE>, which comes with Automake.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_CPP</B>
+ <DD><A NAME="IDX473"></A>
+ <A NAME="IDX474"></A>
+ <A NAME="IDX475"></A>
+ 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>
+ If the current language is C (see section <A HREF="autoconf.html#SEC78">Language Choice</A>), many of the
+ specific test macros use the value of <CODE>CPP</CODE> indirectly by calling
+ <CODE>AC_TRY_CPP</CODE>, <CODE>AC_CHECK_HEADER</CODE>, <CODE>AC_EGREP_HEADER</CODE>, or
+ <CODE>AC_EGREP_CPP</CODE>.
+
+
+ <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.
+ </DL>
+
+
+ <P>
+ The following macros check for C compiler or machine architecture
+ features. To check for characteristics not listed here, use
+ <CODE>AC_TRY_COMPILE</CODE> (see section <A HREF="autoconf.html#SEC70">Examining Syntax</A>) or <CODE>AC_TRY_RUN</CODE>
+ (see section <A HREF="autoconf.html#SEC72">Checking Run Time Behavior</A>)
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_BIGENDIAN</B> <I>(@ovar{action-if-true}, @ovar{action-if-false}, @ovar{action-if-unknown})</I>
+ <DD><A NAME="IDX476"></A>
+ <A NAME="IDX477"></A>
+ <A NAME="IDX478"></A>
+ <A NAME="IDX479"></A>
+ 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 less significant byte first (like Intel and VAX CPUs), execute
+ <VAR>action-if-false</VAR>.
+
+
+ <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>
+ 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. And finally, the default for <VAR>action-if-unknown</VAR> is to
+ abort configure and tell the installer which variable he should preset
+ to bypass this test.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_CONST</B>
+ <DD><A NAME="IDX480"></A>
+ <A NAME="IDX481"></A>
+ <A NAME="IDX482"></A>
+ If the C compiler does not fully support the ANSI C qualifier
+ <CODE>const</CODE>, 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 <TT>`Makefile'</TT> or configuration header file will
+ define it as empty.
+
+
+ <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:
+
+
+
+ <PRE>
+ const int foo;
+ </PRE>
+
+ <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>
+ If @command{autoconf} 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_VOLATILE</B>
+ <DD><A NAME="IDX483"></A>
+ <A NAME="IDX484"></A>
+ <A NAME="IDX485"></A>
+ 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 <TT>`Makefile'</TT> or configuration header will define it as
+ empty.
+
+
+ <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 will compile, when it wouldn't before.
+
+
+ <P>
+ In general, the <CODE>volatile</CODE> keyword is a feature of ANSI C, 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 defined <CODE>__STDC__</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_INLINE</B>
+ <DD><A NAME="IDX486"></A>
+ <A NAME="IDX487"></A>
+ <A NAME="IDX488"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_CHAR_UNSIGNED</B>
+ <DD><A NAME="IDX489"></A>
+ <A NAME="IDX490"></A>
+ <A NAME="IDX491"></A>
+ If the C type <CODE>char</CODE> is unsigned, define <CODE>__CHAR_UNSIGNED__</CODE>,
+ unless the C compiler predefines it.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_LONG_DOUBLE</B>
+ <DD><A NAME="IDX492"></A>
+ <A NAME="IDX493"></A>
+ <A NAME="IDX494"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_STRINGIZE</B>
+ <DD><A NAME="IDX495"></A>
+ <A NAME="IDX496"></A>
+ <A NAME="IDX497"></A>
+ 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:
+
+
+
+ <PRE>
+ #define x(y) #y
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_PROTOTYPES</B>
+ <DD><A NAME="IDX498"></A>
+ <A NAME="IDX499"></A>
+ <A NAME="IDX500"></A>
+ <A NAME="IDX501"></A>
+ <A NAME="IDX502"></A>
+ Check to see if function prototypes are understood by the compiler. If
+ so, define <CODE>PROTOTYPES</CODE> and <CODE>__PROTOTYPES</CODE>.
+ In the case the compiler does not handle
+ prototypes, you should use <CODE>ansi2knr</CODE>, which comes with the
+ Automake distribution, to unprotoize function definitions. For
+ function prototypes, you should first define <CODE>PARAMS</CODE>:
+
+
+
+ <PRE>
+ #ifndef PARAMS
+ # if PROTOTYPES
+ # define PARAMS(protos) protos
+ # else /* no PROTOTYPES */
+ # define PARAMS(protos) ()
+ # endif /* no PROTOTYPES */
+ #endif
+ </PRE>
+
+ <P>
+ then use it this way:
+
+
+
+ <PRE>
+ size_t my_strlen PARAMS ((const char *));
+ </PRE>
+
+ </DL>
+
+ <P>
+ This macro also defines <CODE>__PROTOTYPES</CODE>; this is for the benefit of
+ header files that cannot use macros that infringe on user name space.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_GCC_TRADITIONAL</B>
+ <DD><A NAME="IDX503"></A>
+ <A NAME="IDX504"></A>
+ <A NAME="IDX505"></A>
+ Add @option{-traditional} to output variable <CODE>CC</CODE> if using the
+ GNU C compiler and <CODE>ioctl</CODE> does not work properly without
+ @option{-traditional}. That usually happens when the fixed header files
+ have not been installed on an old system. Since recent versions of the
+ GNU C compiler fix the header files automatically when installed,
+ this is becoming a less prevalent problem.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC64" HREF="autoconf_toc.html#TOC64">C++ Compiler Characteristics</A></H3>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_CXX</B> <I>(@ovar{compiler-search-list})</I>
+ <DD><A NAME="IDX506"></A>
+ <A NAME="IDX507"></A>
+ <A NAME="IDX508"></A>
+ <A NAME="IDX509"></A>
+ Determine a C++ compiler to use. Check if 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>
+ 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>
+ This macro may, however, be invoked with an optional first argument
+ which, if specified, must be a space 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:
+
+
+
+ <PRE>
+ AC_PROG_CXX(cl KCC CC cxx cc++ xlC aCC c++ g++ egcs gcc)
+ </PRE>
+
+ <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 @option{-g -O2} for the GNU C++ compiler (@option{-O2} on
+ systems where G++ does not accept @option{-g}), or @option{-g} for other
+ compilers.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_CXXCPP</B>
+ <DD><A NAME="IDX510"></A>
+ <A NAME="IDX511"></A>
+ <A NAME="IDX512"></A>
+ 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 only portable to run <CODE>CXXCPP</CODE> on files with a <TT>`.c'</TT>,
+ <TT>`.C'</TT>, or <TT>`.cc'</TT> extension.
+
+
+ <P>
+ If the current language is C++ (see section <A HREF="autoconf.html#SEC78">Language Choice</A>), many of the
+ specific test macros use the value of <CODE>CXXCPP</CODE> indirectly by
+ calling <CODE>AC_TRY_CPP</CODE>, <CODE>AC_CHECK_HEADER</CODE>,
+ <CODE>AC_EGREP_HEADER</CODE>, or <CODE>AC_EGREP_CPP</CODE>.
+
+
+ <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++.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC65" HREF="autoconf_toc.html#TOC65">Fortran 77 Compiler Characteristics</A></H3>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_F77</B> <I>(@ovar{compiler-search-list})</I>
+ <DD><A NAME="IDX513"></A>
+ <A NAME="IDX514"></A>
+ <A NAME="IDX515"></A>
+ <A NAME="IDX516"></A>
+ 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>
+ This macro may, however, be invoked with an optional first argument
+ which, if specified, must be a space 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:
+
+
+
+ <PRE>
+ AC_PROG_F77(fl32 f77 fort77 xlf cf77 g77 f90 xlf90)
+ </PRE>
+
+ <P>
+ If using <CODE>g77</CODE> (the GNU Fortran 77 compiler), then
+ <CODE>AC_PROG_F77</CODE> will 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 @option{-g -02} for <CODE>g77</CODE> (or @option{-O2}
+ where <CODE>g77</CODE> does not accept @option{-g}). Otherwise, set
+ <CODE>FFLAGS</CODE> to @option{-g} for all other Fortran 77 compilers.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROG_F77_C_O</B>
+ <DD><A NAME="IDX517"></A>
+ <A NAME="IDX518"></A>
+ <A NAME="IDX519"></A>
+ Test if the Fortran 77 compiler accepts the options @option{-c} and
+ @option{-o} simultaneously, and define <CODE>F77_NO_MINUS_C_MINUS_O</CODE> if it
+ does not.
+ </DL>
+
+
+ <P>
+ The following macros check for Fortran 77 compiler characteristics. To
+ check for characteristics not listed here, use <CODE>AC_TRY_COMPILE</CODE>
+ (see section <A HREF="autoconf.html#SEC70">Examining Syntax</A>) or <CODE>AC_TRY_RUN</CODE> (see section <A HREF="autoconf.html#SEC72">Checking Run Time Behavior</A>),
+ making sure to first set the current language to Fortran 77
+ <CODE>AC_LANG(Fortran 77)</CODE> (see section <A HREF="autoconf.html#SEC78">Language Choice</A>).
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_F77_LIBRARY_LDFLAGS</B>
+ <DD><A NAME="IDX520"></A>
+ <A NAME="IDX521"></A>
+ <A NAME="IDX522"></A>
+ Determine the linker flags (e.g. @option{-L} and @option{-l}) for the
+ <EM>Fortran 77 intrinsic and run-time libraries</EM> that are required to
+ successfully link a Fortran 77 program or shared library. The output
+ variable <CODE>FLIBS</CODE> is set to these flags.
+
+
+ <P>
+ This macro is intended to be used in those situations when it is
+ necessary to mix, e.g. C++ and Fortran 77 source code into a single
+ program or shared library (see section `Mixing Fortran 77 With C and C++' in <CITE>GNU Automake</CITE>).
+
+
+ <P>
+ For example, if object files from a C++ and Fortran 77 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>
+ However, the Fortran 77 intrinsic and run-time 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, the macro
+ <CODE>AC_F77_LIBRARY_LDFLAGS</CODE> was created to determine these Fortran 77
+ libraries.
+
+
+ <P>
+ The macro <CODE>AC_F77_DUMMY_MAIN</CODE> or <CODE>AC_F77_MAIN</CODE> will probably
+ also be necessary to link C/C++ with Fortran; see below.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_F77_DUMMY_MAIN</B> <I>(@ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX523"></A>
+ <A NAME="IDX524"></A>
+ <A NAME="IDX525"></A>
+ With many compilers, the Fortran libraries detected by
+ <CODE>AC_F77_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 e.g. <CODE>MAIN__</CODE> to run the
+ user's program. The <CODE>AC_F77_DUMMY_MAIN</CODE> or <CODE>AC_F77_MAIN</CODE>
+ macro figures out how to deal with this interaction.
+
+
+ <P>
+ When using Fortran for purely numerical functions (no I/O, etcetera),
+ users often prefer to provide their 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> detects whether any such
+ routine is <EM>required</EM> for linking, and what its name is; the shell
+ variable <CODE>F77_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>
+ By default, <VAR>action-if-found</VAR> defines <CODE>F77_DUMMY_MAIN</CODE> to the
+ name of this routine (e.g. <CODE>MAIN__</CODE>) <EM>if</EM> it is required.
+ @ovar{action-if-not-found} defaults to exiting with an error.
+
+
+ <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:
+
+
+
+ <PRE>
+ #ifdef F77_DUMMY_MAIN
+ # ifdef __cplusplus
+ extern "C"
+ # endif
+ int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ </PRE>
+
+ <P>
+ Note that <CODE>AC_F77_DUMMY_MAIN</CODE> is called automatically from
+ <CODE>AC_F77_WRAPPERS</CODE>; there is generally no need to call it explicitly
+ unless one wants to change the default actions.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_F77_MAIN</B>
+ <DD><A NAME="IDX526"></A>
+ <A NAME="IDX527"></A>
+ <A NAME="IDX528"></A>
+ As discussed above for <CODE>AC_F77_DUMMY_MAIN</CODE>, many Fortran libraries
+ allow you to provide an entry point called e.g. <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> macro detects whether it is <EM>possible</EM> to
+ utilize such an alternate main function, and defines <CODE>F77_MAIN</CODE> to
+ the name of the function. (If no alternate main function name is found,
+ <CODE>F77_MAIN</CODE> is simply defined to <CODE>main</CODE>.)
+
+
+ <P>
+ Thus, when calling Fortran routines from C that perform things like I/O,
+ one should use this macro and name the "main" function <CODE>F77_MAIN</CODE>
+ instead of <CODE>main</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_F77_WRAPPERS</B>
+ <DD><A NAME="IDX529"></A>
+ <A NAME="IDX530"></A>
+ <A NAME="IDX531"></A>
+ <A NAME="IDX532"></A>
+ Defines C macros <CODE>F77_FUNC(name,NAME)</CODE> and
+ <CODE>F77_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 77 compiler.
+
+
+ <P>
+ Fortran 77 is case-insensitive, and in order to achieve this the Fortran
+ 77 compiler converts all identifiers into a canonical case and format.
+ To call a Fortran 77 subroutine from C or to write a C function that is
+ callable from Fortran 77, the C program must explicitly use identifiers
+ in the format expected by the Fortran 77 compiler. In order to do this,
+ one simply wraps all C identifiers in one of the macros provided by
+ <CODE>AC_F77_WRAPPERS</CODE>. For example, suppose you have the following
+ Fortran 77 subroutine:
+
+
+
+ <PRE>
+ subroutine foobar(x,y)
+ double precision x, y
+ y = 3.14159 * x
+ return
+ end
+ </PRE>
+
+ <P>
+ You would then declare its prototype in C or C++ as:
+
+
+
+ <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>
+
+ <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 (see section `Mixing Fortran 77 With C and C++' in <CITE>GNU Automake</CITE>).
+
+
+ <P>
+ Although Autoconf tries to be intelligent about detecting the
+ name-mangling scheme of the Fortran 77 compiler, there may be Fortran 77
+ compilers that it doesn't support yet. In this case, the above code
+ will generate a compile-time error, but some other behavior
+ (e.g. disabling Fortran-related features) can be induced by checking
+ whether the <CODE>F77_FUNC</CODE> macro is defined.
+
+
+ <P>
+ Now, to call that routine from a C program, we would do something like:
+
+
+
+ <PRE>
+ {
+ double x = 2.7183, y;
+ FOOBAR_F77(&x, &y);
+ }
+ </PRE>
+
+ <P>
+ If the Fortran 77 identifier contains an underscore
+ (e.g. <CODE>foo_bar</CODE>), you should use <CODE>F77_FUNC_</CODE> instead of
+ <CODE>F77_FUNC</CODE> (with the same arguments). This is because some Fortran
+ 77 compilers mangle names differently if they contain an underscore.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_F77_FUNC</B> <I>(<VAR>name</VAR>, @ovar{shellvar})</I>
+ <DD><A NAME="IDX533"></A>
+ <A NAME="IDX534"></A>
+ 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 77 linker (see also <CODE>AC_F77_WRAPPERS</CODE>). <VAR>shellvar</VAR> is
+ optional; if it is not supplied, the shell variable will be 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++.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC66" HREF="autoconf_toc.html#TOC66">System Services</A></H2>
+
+ <P>
+ The following macros check for operating system services or capabilities.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PATH_X</B>
+ <DD><A NAME="IDX535"></A>
+ <A NAME="IDX536"></A>
+ Try to locate the X Window System include files and libraries. If the
+ user gave the command line options @option{--x-includes=<VAR>dir</VAR>} and
+ @option{--x-libraries=<VAR>dir</VAR>}, use those directories. If either or
+ both were not given, get the missing values by running <CODE>xmkmf</CODE> on a
+ trivial <TT>`Imakefile'</TT> and examining the <TT>`Makefile'</TT> that it
+ produces. If that fails (such as if <CODE>xmkmf</CODE> is not present), look
+ for them 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>
+ If both methods fail, or the user gave the command line option
+ @option{--without-x}, set the shell variable <CODE>no_x</CODE> to <SAMP>`yes'</SAMP>;
+ otherwise set it to the empty string.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PATH_XTRA</B>
+ <DD><A NAME="IDX537"></A>
+ <A NAME="IDX538"></A>
+ <A NAME="IDX539"></A>
+ <A NAME="IDX540"></A>
+ <A NAME="IDX541"></A>
+ <A NAME="IDX542"></A>
+ <A NAME="IDX543"></A>
+ 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>
+ 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 @option{-lX11}, and adds
+ any found to the output variable <CODE>X_PRE_LIBS</CODE>.
+
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SYS_INTERPRETER</B>
+ <DD><A NAME="IDX544"></A>
+ <A NAME="IDX545"></A>
+ Check whether the system supports starting scripts with a line of the
+ form <SAMP>`#! /bin/csh'</SAMP> to select the interpreter to use for the script.
+ After running this macro, shell code in @command{configure.ac} can check
+ the shell variable <CODE>interpval</CODE>; it will be set to <SAMP>`yes'</SAMP>
+ if the system supports <SAMP>`#!'</SAMP>, <SAMP>`no'</SAMP> if not.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SYS_LARGEFILE</B>
+ <DD><A NAME="IDX546"></A>
+ <A NAME="IDX547"></A>
+ <A NAME="IDX548"></A>
+ <A NAME="IDX549"></A>
+ <A NAME="IDX550"></A>
+ Arrange for
+ @href{http://www.sas.com/standards/large.file/x_open.20Mar96.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>
+ Large-file support can be disabled by configuring with the
+ @option{--disable-largefile} option.
+
+
+ <P>
+ If you use this macro, check that your program works even when
+ <CODE>off_t</CODE> is longer than <CODE>long</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) X)</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SYS_LONG_FILE_NAMES</B>
+ <DD><A NAME="IDX551"></A>
+ <A NAME="IDX552"></A>
+ <A NAME="IDX553"></A>
+ If the system supports file names longer than 14 characters, define
+ <CODE>HAVE_LONG_FILE_NAMES</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SYS_POSIX_TERMIOS</B>
+ <DD><A NAME="IDX554"></A>
+ <A NAME="IDX555"></A>
+ <A NAME="IDX556"></A>
+ <A NAME="IDX557"></A>
+ Check to see if POSIX termios headers and functions are available on the
+ system. If so, set the shell variable <CODE>am_cv_sys_posix_termios</CODE> to
+ <SAMP>`yes'</SAMP>. If not, set the variable to <SAMP>`no'</SAMP>.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC67" HREF="autoconf_toc.html#TOC67">UNIX Variants</A></H2>
+
+ <P>
+ The following macros check for certain operating systems that need
+ special treatment for some programs, due to exceptional oddities in
+ their header files or libraries. These macros are warts; they will be
+ replaced by a more systematic approach, based on the functions they make
+ available or the environments they provide.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_AIX</B>
+ <DD><A NAME="IDX558"></A>
+ <A NAME="IDX559"></A>
+ <A NAME="IDX560"></A>
+ If on AIX, define <CODE>_ALL_SOURCE</CODE>. Allows the use of some BSD
+ functions. Should be called before any macros that run the C compiler.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ISC_POSIX</B>
+ <DD><A NAME="IDX561"></A>
+ <A NAME="IDX562"></A>
+ <A NAME="IDX563"></A>
+ For INTERACTIVE UNIX (ISC), add @option{-lcposix} to output
+ variable <CODE>LIBS</CODE> if necessary for POSIX facilities. Call this
+ after <CODE>AC_PROG_CC</CODE> and before any other macros that use POSIX
+ interfaces. INTERACTIVE UNIX is no longer sold, and Sun says that
+ they will drop support for it on 2006-07-23, so this macro is becoming
+ obsolescent.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MINIX</B>
+ <DD><A NAME="IDX564"></A>
+ <A NAME="IDX565"></A>
+ <A NAME="IDX566"></A>
+ <A NAME="IDX567"></A>
+ <A NAME="IDX568"></A>
+ If on Minix, define <CODE>_MINIX</CODE> and <CODE>_POSIX_SOURCE</CODE> and define
+ <CODE>_POSIX_1_SOURCE</CODE> to be 2. This allows the use of POSIX
+ facilities. Should be called before any macros that run the C compiler.
+ </DL>
+
+
+
+
+ <H1><A NAME="SEC68" HREF="autoconf_toc.html#TOC68">Writing Tests</A></H1>
+
+ <P>
+ If the existing feature tests don't do something you need, you have to
+ write new ones. These macros are the building blocks. They provide
+ ways for other macros to check whether various kinds of features are
+ available and report the results.
+
+
+ <P>
+ This chapter contains some suggestions and some of the reasons why the
+ existing tests are written the way they are. You can also learn a lot
+ about how to write Autoconf tests by looking at the existing ones. If
+ something goes wrong in one or more of the Autoconf tests, this
+ information can help you understand the assumptions behind them, which
+ might help you figure out how to best solve the problem.
+
+
+ <P>
+ These macros check the output of the C compiler system. They do
+ not cache the results of their tests for future use (see section <A HREF="autoconf.html#SEC82">Caching Results</A>), because they don't know enough about the information they are
+ checking for to generate a cache variable name. They also do not print
+ any messages, for the same reason. The checks for particular kinds of C
+ features call these macros and do cache their results and print messages
+ about what they're checking for.
+
+
+ <P>
+ When you write a feature test that could be applicable to more than one
+ software package, the best thing to do is encapsulate it in a new macro.
+ See section <A HREF="autoconf.html#SEC101">Writing Autoconf Macros</A>, for how to do that.
+
+
+
+
+ <H2><A NAME="SEC69" HREF="autoconf_toc.html#TOC69">Examining Declarations</A></H2>
+
+ <P>
+ The macro <CODE>AC_TRY_CPP</CODE> is used to check whether particular header
+ files exist. You can check for one at a time, or more than one if you
+ need several header files to all exist for some purpose.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TRY_CPP</B> <I>(<VAR>input</VAR>, @ovar{action-if-true}, @ovar{action-if-false})</I>
+ <DD><A NAME="IDX569"></A>
+ <A NAME="IDX570"></A>
+ If the preprocessor produces no error messages while processing the
+ <VAR>input</VAR> (typically includes), run shell commands
+ <VAR>action-if-true</VAR>. Otherwise run shell commands
+ <VAR>action-if-false</VAR>. Beware that <VAR>input</VAR> is double quoted. Shell
+ variable, back quote, and backslash substitutions are performed on
+ <VAR>input</VAR>.
+
+
+ <P>
+ This macro uses <CODE>CPPFLAGS</CODE>, but not <CODE>CFLAGS</CODE>, because
+ @option{-g}, @option{-O}, etc. are not valid options to many C
+ preprocessors.
+ </DL>
+
+
+ <P>
+ Here is how to find out whether a header file contains a particular
+ declaration, such as a typedef, a structure, a structure member, or a
+ function. Use <CODE>AC_EGREP_HEADER</CODE> instead of running <CODE>grep</CODE>
+ directly on the header file; on some systems the symbol might be defined
+ in another header file that the file you are checking <SAMP>`#include'</SAMP>s.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_EGREP_HEADER</B> <I>(<VAR>pattern</VAR>, <VAR>header-file</VAR>, <VAR>action-if-found</VAR>, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX571"></A>
+ <A NAME="IDX572"></A>
+ If the output of running the preprocessor on the system header file
+ <VAR>header-file</VAR> matches the <CODE>egrep</CODE> regular expression
+ <VAR>pattern</VAR>, execute shell commands <VAR>action-if-found</VAR>, otherwise
+ execute <VAR>action-if-not-found</VAR>.
+ </DL>
+
+
+ <P>
+ To check for C preprocessor symbols, either defined by header files or
+ predefined by the C preprocessor, use <CODE>AC_EGREP_CPP</CODE>. Here is an
+ example of the latter:
+
+
+
+ <PRE>
+ AC_EGREP_CPP(yes,
+ [#ifdef _AIX
+ yes
+ #endif
+ ], is_aix=yes, is_aix=no)
+ </PRE>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_EGREP_CPP</B> <I>(<VAR>pattern</VAR>, <VAR>program</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX573"></A>
+ <A NAME="IDX574"></A>
+ <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
+ <CODE>egrep</CODE> regular expression <VAR>pattern</VAR>, execute shell commands
+ <VAR>action-if-found</VAR>, otherwise execute <VAR>action-if-not-found</VAR>.
+
+
+ <P>
+ This macro calls <CODE>AC_PROG_CPP</CODE> or <CODE>AC_PROG_CXXCPP</CODE> (depending
+ on which language is current, see section <A HREF="autoconf.html#SEC78">Language Choice</A>), if it hasn't
+ been called already.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC70" HREF="autoconf_toc.html#TOC70">Examining Syntax</A></H2>
+
+ <P>
+ To check for a syntax feature of the C, C++ or Fortran 77 compiler, such
+ as whether it recognizes a certain keyword, use <CODE>AC_TRY_COMPILE</CODE> to
+ try to compile a small program that uses that feature. You can also use
+ it to check for structures and structure members that are not present on
+ all systems.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TRY_COMPILE</B> <I>(<VAR>includes</VAR>, <VAR>function-body</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX575"></A>
+ <A NAME="IDX576"></A>
+ Create a test program in the current language (see section <A HREF="autoconf.html#SEC78">Language Choice</A>)
+ to see whether a function whose body consists of <VAR>function-body</VAR> can
+ be compiled. If the file compiles successfully, run shell commands
+ <VAR>action-if-found</VAR>, otherwise run <VAR>action-if-not-found</VAR>.
+
+
+ <P>
+ This macro double quotes both <VAR>includes</VAR> and <VAR>function-body</VAR>.
+
+
+ <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> will be ignored if
+ the currently selected language is Fortran 77). This macro also uses
+ <CODE>CFLAGS</CODE> or <CODE>CXXFLAGS</CODE> if either C or C++ is the currently
+ selected language, as well as <CODE>CPPFLAGS</CODE>, when compiling. If
+ Fortran 77 is the currently selected language then <CODE>FFLAGS</CODE> will be
+ used when compiling.
+
+
+ <P>
+ This macro does not try to link; use <CODE>AC_TRY_LINK</CODE> if you need to
+ do that (see section <A HREF="autoconf.html#SEC71">Examining Libraries</A>).
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC71" HREF="autoconf_toc.html#TOC71">Examining Libraries</A></H2>
+
+ <P>
+ To check for a library, a function, or a global variable, Autoconf
+ @command{configure} scripts try to compile and link a small program that
+ uses it. This is unlike Metaconfig, which by default uses <CODE>nm</CODE>
+ or <CODE>ar</CODE> on the C library to try to figure out which functions are
+ available. Trying to link with the function is usually a more reliable
+ approach because it avoids dealing with the variations in the options
+ and output formats of <CODE>nm</CODE> and <CODE>ar</CODE> and in the location of the
+ standard libraries. It also allows configuring for cross-compilation or
+ checking a function's runtime behavior if needed. On the other hand, it
+ can be slower than scanning the libraries once.
+
+
+ <P>
+ A few systems have linkers that do not return a failure exit status when
+ there are unresolved functions in the link. This bug makes the
+ configuration scripts produced by Autoconf unusable on those systems.
+ However, some of them can be given options that make the exit status
+ correct. This is a problem that Autoconf does not currently handle
+ automatically. If users encounter this problem, they might be able to
+ solve it by setting <CODE>LDFLAGS</CODE> in the environment to pass whatever
+ options the linker needs (for example, @option{-Wl,-dn} on @sc{mips
+ risc/os}).
+
+
+ <P>
+ <CODE>AC_TRY_LINK</CODE> is used to compile test programs to test for
+ functions and global variables. It is also used by <CODE>AC_CHECK_LIB</CODE>
+ to check for libraries (see section <A HREF="autoconf.html#SEC43">Library Files</A>), by adding the library being
+ checked for to <CODE>LIBS</CODE> temporarily and trying to link a small
+ program.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TRY_LINK</B> <I>(<VAR>includes</VAR>, <VAR>function-body</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX577"></A>
+ <A NAME="IDX578"></A>
+ Depending on the current language (see section <A HREF="autoconf.html#SEC78">Language Choice</A>), 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>
+ This macro double quotes both <VAR>includes</VAR> and <VAR>function-body</VAR>.
+
+
+ <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> will be ignored if
+ the currently selected language is Fortran 77). This macro also uses
+ <CODE>CFLAGS</CODE> or <CODE>CXXFLAGS</CODE> if either C or C++ is the currently
+ selected language, as well as <CODE>CPPFLAGS</CODE>, when compiling. If
+ Fortran 77 is the currently selected language then <CODE>FFLAGS</CODE> will be
+ used when compiling. However, both <CODE>LDFLAGS</CODE> and <CODE>LIBS</CODE> will
+ be used during linking in all cases.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TRY_LINK_FUNC</B> <I>(<VAR>function</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX579"></A>
+ <A NAME="IDX580"></A>
+ Depending on the current language (see section <A HREF="autoconf.html#SEC78">Language Choice</A>), create a
+ test program to see whether a program whose body consists of
+ a prototype of and a call to <VAR>function</VAR> can be compiled and linked.
+
+
+ <P>
+ If the file compiles and links successfully, run shell commands
+ <VAR>action-if-found</VAR>, otherwise run <VAR>action-if-not-found</VAR>.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC72" HREF="autoconf_toc.html#TOC72">Checking Run Time Behavior</A></H2>
+
+ <P>
+ Sometimes you need to find out how a system performs at run time, such
+ as whether a given function has a certain capability or bug. If you
+ can, make such checks when your program runs instead of when it is
+ configured. You can check for things like the machine's endianness when
+ your program initializes itself.
+
+
+ <P>
+ If you really need to test for a run-time behavior while configuring,
+ you can write a test program to determine the result, and compile and
+ run it using <CODE>AC_TRY_RUN</CODE>. Avoid running test programs if
+ possible, because this prevents people from configuring your package for
+ cross-compiling.
+
+
+
+
+ <H3><A NAME="SEC73" HREF="autoconf_toc.html#TOC73">Running Test Programs</A></H3>
+
+ <P>
+ Use the following macro if you need to test run-time behavior of the
+ system while configuring.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TRY_RUN</B> <I>(<VAR>program</VAR>, @ovar{action-if-true}, @ovar{action-if-false}, @ovar{action-if-cross-compiling})</I>
+ <DD><A NAME="IDX581"></A>
+ <A NAME="IDX582"></A>
+ 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>
+ This macro double quotes <VAR>program</VAR>, the text of a program in the
+ current language (see section <A HREF="autoconf.html#SEC78">Language Choice</A>), on which shell variable and
+ back quote substitutions are performed. This macro uses <CODE>CFLAGS</CODE>
+ or <CODE>CXXFLAGS</CODE>, <CODE>CPPFLAGS</CODE>, <CODE>LDFLAGS</CODE>, and <CODE>LIBS</CODE>
+ when compiling.
+
+
+ <P>
+ If the C compiler being used does not produce executables that run on
+ the system where @command{configure} 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, @command{configure} prints
+ an error message and exits.
+
+
+ <P>
+ In the <VAR>action-if-false</VAR> section, the exit status of the program is
+ available in the shell variable <SAMP>`$?'</SAMP>, but be very careful to limit
+ yourself to positive values smaller than 127; bigger values shall be
+ saved into a file by the <VAR>program</VAR>. Note also that you have simply
+ no guarantee that this exit status is issued by the <VAR>program</VAR>, or by
+ the failure of its compilation. In other words, use this feature if
+ sadist only, it was reestablished because the Autoconf maintainers grew
+ tired of receiving "bug reports".
+ </DL>
+
+
+ <P>
+ Try to provide a pessimistic default value to use when cross-compiling
+ makes run-time tests impossible. You do this by passing the optional
+ last argument to <CODE>AC_TRY_RUN</CODE>. @command{autoconf} prints a warning
+ message when creating @command{configure} each time it encounters a call to
+ <CODE>AC_TRY_RUN</CODE> with no <VAR>action-if-cross-compiling</VAR> argument
+ given. You may ignore the warning, though users will not be able to
+ configure your package for cross-compiling. A few of the macros
+ distributed with Autoconf produce this warning message.
+
+
+ <P>
+ To configure for cross-compiling you can also choose a value for those
+ parameters based on the canonical system name (see section <A HREF="autoconf.html#SEC121">Manual Configuration</A>). Alternatively, set up a test results cache file with
+ the correct values for the host system (see section <A HREF="autoconf.html#SEC82">Caching Results</A>).
+
+
+ <P>
+ To provide a default for calls of <CODE>AC_TRY_RUN</CODE> that are embedded in
+ other macros, including a few of the ones that come with Autoconf, you
+ can call <CODE>AC_PROG_CC</CODE> before running them. Then, if the shell
+ variable <CODE>cross_compiling</CODE> is set to <SAMP>`yes'</SAMP>, use an alternate
+ method to get the results instead of calling the macros.
+
+
+
+
+ <H3><A NAME="SEC74" HREF="autoconf_toc.html#TOC74">Guidelines for Test Programs</A></H3>
+
+ <P>
+ Test programs should not write anything to the standard output. They
+ should return 0 if the test succeeds, nonzero otherwise, so that success
+ can be distinguished easily from a core dump or other failure;
+ segmentation violations and other failures produce a nonzero exit
+ status. Test programs should <CODE>exit</CODE>, not <CODE>return</CODE>, from
+ <CODE>main</CODE>, because on some systems (old Suns, at least) the argument
+ to <CODE>return</CODE> in <CODE>main</CODE> is ignored.
+
+
+ <P>
+ Test programs can use <CODE>#if</CODE> or <CODE>#ifdef</CODE> to check the values of
+ preprocessor macros defined by tests that have already run. For
+ example, if you call <CODE>AC_HEADER_STDC</CODE>, then later on in
+ <TT>`configure.ac'</TT> you can have a test program that includes an
+ ANSI C header file conditionally:
+
+
+
+ <PRE>
+ #if STDC_HEADERS
+ # include <stdlib.h>
+ #endif
+ </PRE>
+
+ <P>
+ If a test program needs to use or create a data file, give it a name
+ that starts with <TT>`conftest'</TT>, such as <TT>`conftest.data'</TT>. The
+ @command{configure} script cleans up by running <SAMP>`rm -rf conftest*'</SAMP>
+ after running test programs and if the script is interrupted.
+
+
+
+
+ <H3><A NAME="SEC75" HREF="autoconf_toc.html#TOC75">Test Functions</A></H3>
+
+ <P>
+ Function declarations in test programs should have a prototype
+ conditionalized for C++. In practice, though, test programs rarely need
+ functions that take arguments.
+
+
+
+ <PRE>
+ #ifdef __cplusplus
+ foo (int i)
+ #else
+ foo (i) int i;
+ #endif
+ </PRE>
+
+ <P>
+ Functions that test programs declare should also be conditionalized for
+ C++, which requires <SAMP>`extern "C"'</SAMP> prototypes. Make sure to not
+ include any header files containing clashing prototypes.
+
+
+
+ <PRE>
+ #ifdef __cplusplus
+ extern "C" void *malloc (size_t);
+ #else
+ char *malloc ();
+ #endif
+ </PRE>
+
+ <P>
+ If a test program calls a function with invalid parameters (just to see
+ whether it exists), organize the program to ensure that it never invokes
+ that function. You can do this by calling it in another function that is
+ never invoked. You can't do it by putting it after a call to
+ <CODE>exit</CODE>, because GCC version 2 knows that <CODE>exit</CODE> never returns
+ and optimizes out any code that follows it in the same block.
+
+
+ <P>
+ If you include any header files, make sure to call the functions
+ relevant to them with the correct number of arguments, even if they are
+ just 0, to avoid compilation errors due to prototypes. GCC version 2
+ has internal prototypes for several functions that it automatically
+ inlines; for example, <CODE>memcpy</CODE>. To avoid errors when checking for
+ them, either pass them the correct number of arguments or redeclare them
+ with a different return type (such as <CODE>char</CODE>).
+
+
+
+
+ <H2><A NAME="SEC76" HREF="autoconf_toc.html#TOC76">Systemology</A></H2>
+
+ <P>
+ This section aims at presenting some systems and pointers to
+ documentation. It may help you addressing particular problems reported
+ by users.
+
+
+ <DL COMPACT>
+
+ <DT>QNX 4.25
+ <DD>
+ <A NAME="IDX583"></A>
+ QNX is a realtime operating system running on Intel architecture
+ meant to be scalable from the small embedded systems to hundred
+ processor super-computer. It claims to be POSIX certified. More
+ information is available on the @href{www.qnx.com, QNX home page},
+ including the @href{http://support.qnx.com/support/docs/qnx4/, QNX
+ man pages}.
+ </DL>
+
+
+
+ <H2><A NAME="SEC77" HREF="autoconf_toc.html#TOC77">Multiple Cases</A></H2>
+
+ <P>
+ Some operations are accomplished in several possible ways, depending on
+ the UNIX variant. Checking for them essentially requires a "case
+ statement". Autoconf does not directly provide one; however, it is
+ easy to simulate by using a shell variable to keep track of whether a
+ way to perform the operation has been found yet.
+
+
+ <P>
+ Here is an example that uses the shell variable <CODE>fstype</CODE> to keep
+ track of whether the remaining cases need to be checked.
+
+
+
+ <PRE>
+ AC_MSG_CHECKING([how to get file system type])
+ fstype=no
+ # The order of these tests is important.
+ AC_TRY_CPP([#include <sys/statvfs.h>
+ #include <sys/fstyp.h>],
+ [AC_DEFINE(FSTYPE_STATVFS) fstype=SVR4])
+ if test $fstype = no; then
+ AC_TRY_CPP([#include <sys/statfs.h>
+ #include <sys/fstyp.h>],
+ [AC_DEFINE(FSTYPE_USG_STATFS) fstype=SVR3])
+ fi
+ if test $fstype = no; then
+ AC_TRY_CPP([#include <sys/statfs.h>
+ #include <sys/vmount.h>],
+ [AC_DEFINE(FSTYPE_AIX_STATFS) fstype=AIX])
+ fi
+ # (more cases omitted here)
+ AC_MSG_RESULT([$fstype])
+ </PRE>
+
+
+
+ <H2><A NAME="SEC78" HREF="autoconf_toc.html#TOC78">Language Choice</A></H2>
+ <P>
+ <A NAME="IDX584"></A>
+
+
+ <P>
+ Autoconf-generated @command{configure} scripts check for the C compiler and
+ its features by default. Packages that use other programming languages
+ (maybe more than one, e.g. C and C++) need to test features of the
+ compilers for the respective languages. The following macros determine
+ which programming language is used in the subsequent tests in
+ <TT>`configure.ac'</TT>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG</B> <I>(<VAR>language</VAR>)</I>
+ <DD><A NAME="IDX585"></A>
+ Do compilation tests using the compiler, preprocessor and file
+ extensions for the specified <VAR>language</VAR>.
+
+
+ <P>
+ Supported languages are:
+
+
+ <DL COMPACT>
+
+ <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.
+
+ <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.
+
+ <DT><SAMP>`Fortran 77'</SAMP>
+ <DD>
+ Do compilation tests using <CODE>F77</CODE> and use extension <TT>`.f'</TT> for
+ test programs.
+ </DL>
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG_PUSH</B> <I>(<VAR>language</VAR>)</I>
+ <DD><A NAME="IDX586"></A>
+ <A NAME="IDX587"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG_POP</B> <I>(@ovar{language})</I>
+ <DD><A NAME="IDX588"></A>
+ <A NAME="IDX589"></A>
+ 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>
+ 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...), since Autoconf will detect inconsistencies.
+
+
+
+ <PRE>
+ AC_LANG_PUSH(Fortran 77)
+ # Perform some tests on Fortran 77.
+ # ...
+ AC_LANG_POP(Fortran 77)
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_REQUIRE_CPP</B>
+ <DD><A NAME="IDX590"></A>
+ <A NAME="IDX591"></A>
+ Ensure that whichever preprocessor would currently be used for tests has
+ been found. Calls <CODE>AC_REQUIRE</CODE> (see section <A HREF="autoconf.html#SEC106">Prerequisite Macros</A>) with an
+ argument of either <CODE>AC_PROG_CPP</CODE> or <CODE>AC_PROG_CXXCPP</CODE>,
+ depending on which language is current.
+ </DL>
+
+
+
+
+ <H1><A NAME="SEC79" HREF="autoconf_toc.html#TOC79">Results of Tests</A></H1>
+
+ <P>
+ Once @command{configure} has determined whether a feature exists, what can
+ it do to record that information? There are four sorts of things it can
+ do: define a C preprocessor symbol, set a variable in the output files,
+ save the result in a cache file for future @command{configure} runs, and
+ print a message letting the user know the result of the test.
+
+
+
+
+ <H2><A NAME="SEC80" HREF="autoconf_toc.html#TOC80">Defining C Preprocessor Symbols</A></H2>
+
+ <P>
+ A common action to take in response to a feature test is to define a C
+ preprocessor symbol indicating the results of the test. That is done by
+ calling <CODE>AC_DEFINE</CODE> or <CODE>AC_DEFINE_UNQUOTED</CODE>.
+
+
+ <P>
+ By default, <CODE>AC_OUTPUT</CODE> places the symbols defined by these macros
+ into the output variable <CODE>DEFS</CODE>, which contains an option
+ @option{-D<VAR>symbol</VAR>=<VAR>value</VAR>} for each symbol defined. Unlike in
+ Autoconf version 1, there is no variable <CODE>DEFS</CODE> defined while
+ @command{configure} is running. To check whether Autoconf macros have
+ already defined a certain C preprocessor symbol, test the value of the
+ appropriate cache variable, as in this example:
+
+
+
+ <PRE>
+ AC_CHECK_FUNC(vprintf, [AC_DEFINE(HAVE_VPRINTF)])
+ if test "$ac_cv_func_vprintf" != yes; then
+ AC_CHECK_FUNC(_doprnt, [AC_DEFINE(HAVE_DOPRNT)])
+ fi
+ </PRE>
+
+ <P>
+ If <CODE>AC_CONFIG_HEADERS</CODE> has been called, then instead of creating
+ <CODE>DEFS</CODE>, <CODE>AC_OUTPUT</CODE> creates a header file by substituting the
+ correct values into <CODE>#define</CODE> statements in a template file.
+ See section <A HREF="autoconf.html#SEC27">Configuration Header Files</A>, for more information about this kind of
+ output.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_DEFINE</B> <I>(<VAR>variable</VAR>, @ovar{value}, @ovar{description})</I>
+ <DD><A NAME="IDX592"></A>
+ <A NAME="IDX593"></A>
+ Define C preprocessor variable <VAR>variable</VAR>. If <VAR>value</VAR> is given,
+ set <VAR>variable</VAR> to that value (verbatim), otherwise set it to 1.
+ <VAR>value</VAR> should not contain literal newlines, and if you are not
+ using <CODE>AC_CONFIG_HEADERS</CODE> it should not contain any <SAMP>`#'</SAMP>
+ characters, as <CODE>make</CODE> tends to eat them. To use a shell variable
+ (which you need to do in order to define a value containing the M4 quote
+ characters <SAMP>`['</SAMP> or <SAMP>`]'</SAMP>), use <CODE>AC_DEFINE_UNQUOTED</CODE> instead.
+ <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>:
+
+
+
+ <PRE>
+ AC_DEFINE(EQUATION, "$a > $b")
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_DEFINE_UNQUOTED</B> <I>(<VAR>variable</VAR>, @ovar{value}, @ovar{description})</I>
+ <DD><A NAME="IDX594"></A>
+ <A NAME="IDX595"></A>
+ 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>). 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:
+
+
+
+ <PRE>
+ AC_DEFINE_UNQUOTED(config_machfile, "$machfile")
+ AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups)
+ AC_DEFINE_UNQUOTED($ac_tr_hdr)
+ </PRE>
+
+ </DL>
+
+ <P>
+ Due to the syntactical bizarreness of the Bourne shell, do not use
+ semicolons to separate <CODE>AC_DEFINE</CODE> or <CODE>AC_DEFINE_UNQUOTED</CODE>
+ calls from other macro calls or shell code; that can cause syntax errors
+ in the resulting @command{configure} script. Use either spaces or
+ newlines. That is, do this:
+
+
+
+ <PRE>
+ AC_CHECK_HEADER(elf.h, [AC_DEFINE(SVR4) LIBS="$LIBS -lelf"])
+ </PRE>
+
+ <P>
+ or this:
+
+
+
+ <PRE>
+ AC_CHECK_HEADER(elf.h,
+ [AC_DEFINE(SVR4)
+ LIBS="$LIBS -lelf"])
+ </PRE>
+
+ <P>
+ instead of this:
+
+
+
+ <PRE>
+ AC_CHECK_HEADER(elf.h, [AC_DEFINE(SVR4); LIBS="$LIBS -lelf"])
+ </PRE>
+
+
+
+ <H2><A NAME="SEC81" HREF="autoconf_toc.html#TOC81">Setting Output Variables</A></H2>
+
+ <P>
+ Another way to record the results of tests is to set <EM>output
+ variables</EM>, which are shell variables whose values are substituted into
+ files that @command{configure} outputs. The two macros below create new
+ output variables. See section <A HREF="autoconf.html#SEC23">Preset Output Variables</A>, for a list of output
+ variables that are always available.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SUBST</B> <I>(<VAR>variable</VAR>, @ovar{value})</I>
+ <DD><A NAME="IDX596"></A>
+ <A NAME="IDX597"></A>
+ 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 <TT>`Makefile'</TT>s). This means that <CODE>AC_OUTPUT</CODE> will
+ replace 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. This value of <VAR>variable</VAR> should not contain literal
+ newlines.
+
+
+ <P>
+ If <VAR>value</VAR> is given, in addition assign it to <SAMP>`variable'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SUBST_FILE</B> <I>(<VAR>variable</VAR>)</I>
+ <DD><A NAME="IDX598"></A>
+ <A NAME="IDX599"></A>
+ 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> will replace 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.
+
+
+ <P>
+ This macro is useful for inserting <TT>`Makefile'</TT> fragments containing
+ special dependencies or other <CODE>make</CODE> directives for particular host
+ or target types into <TT>`Makefile'</TT>s. For example, <TT>`configure.ac'</TT>
+ could contain:
+
+
+
+ <PRE>
+ AC_SUBST_FILE(host_frag)
+ host_frag=$srcdir/conf/sun4.mh
+ </PRE>
+
+ <P>
+ and then a <TT>`Makefile.in'</TT> could contain:
+
+
+
+ <PRE>
+ @host_frag@
+ </PRE>
+
+ </DL>
+
+ <P>
+ <A NAME="IDX600"></A>
+ <A NAME="IDX601"></A>
+ Running @command{configure} in different environments can be extremely
+ dangerous. If for instance the user runs <SAMP>`CC=bizarre-cc
+ ./configure'</SAMP>, then the cache, <TT>`config.h'</TT> and many other output
+ files will depend upon @command{bizarre-cc} being the C compiler. If
+ for some reason the user runs @command{/configure} again, or if it is
+ run via <SAMP>`./config.status --recheck'</SAMP>, (See section <A HREF="autoconf.html#SEC26">Automatic Remaking</A>,
+ and see section <A HREF="autoconf.html#SEC145">Recreating a Configuration</A>), then the configuration can be
+ inconsistent, composed of results depending upon two different
+ compilers.
+
+
+ <P>
+ Such variables are named <EM>precious variables</EM>, and can be declared
+ as such by <CODE>AC_ARG_VAR</CODE>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ARG_VAR</B> <I>(<VAR>variable</VAR>, <VAR>description</VAR>)</I>
+ <DD><A NAME="IDX602"></A>
+ <A NAME="IDX603"></A>
+ Declare <VAR>variable</VAR> is a precious variable, and include its
+ <VAR>description</VAR> in the variable section of <SAMP>`./configure --help'</SAMP>.
+
+
+ <P>
+ Being precious means that
+
+ <UL>
+ <LI>
+
+ <VAR>variable</VAR> is <CODE>AC_SUBST</CODE>'d.
+
+ <LI>
+
+ <VAR>variable</VAR> is kept in the cache including if it was not specified on
+ the <SAMP>`./configure'</SAMP> command line. Indeed, while @command{configure}
+ 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.
+
+ <LI>
+
+ <VAR>variable</VAR> is checked for consistency between two
+ @command{configure} runs. For instance:
+
+
+ <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>
+
+ and similarly if the variable is unset, or if its content is changed.
+
+ <LI>
+
+ <VAR>variable</VAR> is kept during automatic reconfiguration
+ (see section <A HREF="autoconf.html#SEC145">Recreating a Configuration</A>) as if it had been passed as a command
+ line argument, including when no cache is used:
+
+
+ <PRE>
+ $ <KBD>CC=/usr/bin/cc ./configure undeclared_var=raboof --silent</KBD>
+ $ <KBD>./config.status --recheck</KBD>
+ running /bin/sh ./configure undeclared_var=raboof --silent \
+ CC=/usr/bin/cc --no-create --no-recursion
+ </PRE>
+
+ </UL>
+
+ </DL>
+
+
+
+ <H2><A NAME="SEC82" HREF="autoconf_toc.html#TOC82">Caching Results</A></H2>
+ <P>
+ <A NAME="IDX604"></A>
+
+
+ <P>
+ To avoid checking for the same features repeatedly in various
+ @command{configure} scripts (or in repeated runs of one script),
+ @command{configure} can optionally save the results of many checks in a
+ <EM>cache file</EM> (see section <A HREF="autoconf.html#SEC84">Cache Files</A>). If a @command{configure} script
+ runs with caching enabled and finds a cache file, it reads the results
+ of previous runs from the cache and avoids rerunning those checks. As a
+ result, @command{configure} can then run much faster than if it had to
+ perform all of the checks every time.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CACHE_VAL</B> <I>(<VAR>cache-id</VAR>, <VAR>commands-to-set-it</VAR>)</I>
+ <DD><A NAME="IDX605"></A>
+ <A NAME="IDX606"></A>
+ 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 @command{configure} was not given the @option{--quiet} or
+ @option{--silent} 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 will be
+ saved in the cache file just before @command{configure} creates its output
+ files. See section <A HREF="autoconf.html#SEC83">Cache Variable Names</A>, for how to choose the name of the
+ <VAR>cache-id</VAR> variable.
+
+
+ <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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CACHE_CHECK</B> <I>(<VAR>message</VAR>, <VAR>cache-id</VAR>, <VAR>commands-to-set-it</VAR>)</I>
+ <DD><A NAME="IDX607"></A>
+ <A NAME="IDX608"></A>
+ 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>
+ 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.
+ </DL>
+
+
+ <P>
+ It is very common to find buggy macros using <CODE>AC_CACHE_VAL</CODE> or
+ <CODE>AC_CACHE_CHECK</CODE>, because people are tempted to call
+ <CODE>AC_DEFINE</CODE> in the <VAR>commands-to-set-it</VAR>. Instead, the code that
+ <EM>follows</EM> the call to <CODE>AC_CACHE_VAL</CODE> should call
+ <CODE>AC_DEFINE</CODE>, by examining the value of the cache variable. For
+ instance, the following macro is broken:
+
+
+
+ <PRE>
+ AC_DEFUN([AC_SHELL_TRUE],
+ [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
+ [ac_cv_shell_true_works=no
+ true && ac_cv_shell_true_works=yes
+ if test $ac_cv_shell_true_works = yes; then
+ AC_DEFINE([TRUE_WORKS], 1
+ [Define if `true(1)' works properly.])
+ fi])
+ ])
+ </PRE>
+
+ <P>
+ This fails if the cache is enabled: the second time this macro is run,
+ <CODE>TRUE_WORKS</CODE> <EM>will not be defined</EM>. The proper implementation
+ is:
+
+
+
+ <PRE>
+ AC_DEFUN([AC_SHELL_TRUE],
+ [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
+ [ac_cv_shell_true_works=no
+ true && ac_cv_shell_true_works=yes])
+ if test $ac_cv_shell_true_works = yes; then
+ AC_DEFINE([TRUE_WORKS], 1
+ [Define if `true(1)' works properly.])
+ fi
+ ])
+ </PRE>
+
+ <P>
+ Also, <VAR>commands-to-set-it</VAR> should not print any messages, for
+ example with <CODE>AC_MSG_CHECKING</CODE>; do that before calling
+ <CODE>AC_CACHE_VAL</CODE>, so the messages are printed regardless of whether
+ the results of the check are retrieved from the cache or determined by
+ running the shell commands.
+
+
+
+
+ <H3><A NAME="SEC83" HREF="autoconf_toc.html#TOC83">Cache Variable Names</A></H3>
+ <P>
+ <A NAME="IDX609"></A>
+
+
+ <P>
+ The names of cache variables should have the following format:
+
+
+
+ <PRE>
+ <VAR>package-prefix</VAR>_cv_<VAR>value-type</VAR>_<VAR>specific-value</VAR>_@ovar{additional-options}
+ </PRE>
+
+ <P>
+ for example, <SAMP>`ac_cv_header_stat_broken'</SAMP> or
+ <SAMP>`ac_cv_prog_gcc_traditional'</SAMP>. The parts of the variable name are:
+
+
+ <DL COMPACT>
+
+ <DT><VAR>package-prefix</VAR>
+ <DD>
+ An abbreviation for your package or organization; the same prefix you
+ begin local Autoconf macros with, except lowercase by convention.
+ For cache values used by the distributed Autoconf macros, this value is
+ <SAMP>`ac'</SAMP>.
+
+ <DT><CODE>_cv_</CODE>
+ <DD>
+ Indicates that this shell variable is a cache value. This string
+ <EM>must</EM> be present in the variable name, including the leading
+ underscore.
+
+ <DT><VAR>value-type</VAR>
+ <DD>
+ A convention for classifying cache values, to produce a rational naming
+ system. The values used in Autoconf are listed in section <A HREF="autoconf.html#SEC103">Macro Names</A>.
+
+ <DT><VAR>specific-value</VAR>
+ <DD>
+ Which member of the class of cache values this test applies to.
+ For example, which function (<SAMP>`alloca'</SAMP>), program (<SAMP>`gcc'</SAMP>), or
+ output variable (<SAMP>`INSTALL'</SAMP>).
+
+ <DT><VAR>additional-options</VAR>
+ <DD>
+ Any particular behavior of the specific member that this test applies to.
+ For example, <SAMP>`broken'</SAMP> or <SAMP>`set'</SAMP>. This part of the name may
+ be omitted if it does not apply.
+ </DL>
+
+ <P>
+ The values assigned to cache variables may not contain newlines.
+ Usually, their values will be boolean (<SAMP>`yes'</SAMP> or <SAMP>`no'</SAMP>) or the
+ names of files or functions; so this is not an important restriction.
+
+
+
+
+ <H3><A NAME="SEC84" HREF="autoconf_toc.html#TOC84">Cache Files</A></H3>
+
+ <P>
+ A cache file is a shell script that caches the results of configure
+ tests run on one system so they can be shared between configure scripts
+ and configure runs. It is not useful on other systems. If its contents
+ are invalid for some reason, the user may delete or edit it.
+
+
+ <P>
+ By default, @command{configure} uses no cache file (technically, it uses
+ @option{--cache-file=/dev/null}), to avoid problems caused by accidental
+ use of stale cache files.
+
+
+ <P>
+ To enable caching, @command{configure} accepts @option{--config-cache} (or
+ @option{-C}) to cache results in the file <TT>`config.cache'</TT>.
+ Alternatively, @option{--cache-file=<VAR>file</VAR>} specifies that
+ <VAR>file</VAR> be the cache file. The cache file is created if it does not
+ exist already. When @command{configure} calls @command{configure} scripts in
+ subdirectories, it uses the @option{--cache-file} argument so that they
+ share the same cache. See section <A HREF="autoconf.html#SEC33">Configuring Other Packages in Subdirectories</A>, for information on
+ configuring subdirectories with the <CODE>AC_CONFIG_SUBDIRS</CODE> macro.
+
+
+ <P>
+ <TT>`config.status'</TT> only pays attention to the cache file if it is
+ given the @option{--recheck} option, which makes it rerun
+ @command{configure}.
+
+
+ <P>
+ It is wrong to try to distribute cache files for particular system types.
+ There is too much room for error in doing that, and too much
+ administrative overhead in maintaining them. For any features that
+ can't be guessed automatically, use the standard method of the canonical
+ system type and linking files (see section <A HREF="autoconf.html#SEC121">Manual Configuration</A>).
+
+
+ <P>
+ The site initialization script can specify a site-wide cache file to
+ use, instead of the usual per-program cache. In this case, the cache
+ file will gradually accumulate information whenever someone runs a new
+ @command{configure} script. (Running @command{configure} merges the new cache
+ results with the existing cache file.) This may cause problems,
+ however, if the system configuration (e.g. the installed libraries or
+ compilers) changes and the stale cache file is not deleted.
+
+
+
+
+ <H3><A NAME="SEC85" HREF="autoconf_toc.html#TOC85">Cache Checkpointing</A></H3>
+
+ <P>
+ If your configure script, or a macro called from configure.ac, happens
+ to abort the configure process, it may be useful to checkpoint the cache
+ a few times at key points using <CODE>AC_CACHE_SAVE</CODE>. Doing so will
+ reduce the amount of time it takes to re-run the configure script with
+ (hopefully) the error that caused the previous abort corrected.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CACHE_LOAD</B>
+ <DD><A NAME="IDX610"></A>
+ <A NAME="IDX611"></A>
+ 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>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CACHE_SAVE</B>
+ <DD><A NAME="IDX612"></A>
+ <A NAME="IDX613"></A>
+ 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 configure.ac.
+ </DL>
+
+
+ <P>
+ For instance:
+
+
+
+ <PRE>
+ ... AC_INIT, etc. ...
+ # Checks for programs.
+ AC_PROG_CC
+ AC_PROG_GCC_TRADITIONAL
+ ... more program checks ...
+ AC_CACHE_SAVE
+
+ # Checks for libraries.
+ AC_CHECK_LIB(nsl, gethostbyname)
+ AC_CHECK_LIB(socket, connect)
+ ... more lib checks ...
+ AC_CACHE_SAVE
+
+ # Might abort...
+ AM_PATH_GTK(1.0.2,, [AC_MSG_ERROR([GTK not in path])])
+ AM_PATH_GTKMM(0.9.5,, [AC_MSG_ERROR([GTK not in path])])
+ ... AC_OUTPUT, etc. ...
+ </PRE>
+
+
+
+ <H2><A NAME="SEC86" HREF="autoconf_toc.html#TOC86">Printing Messages</A></H2>
+ <P>
+ <A NAME="IDX614"></A>
+
+
+ <P>
+ @command{configure} scripts need to give users running them several kinds
+ of information. The following macros print messages in ways appropriate
+ for each kind. The arguments to all of them get enclosed in shell
+ double quotes, so the shell performs variable and back-quote
+ substitution on them.
+
+
+ <P>
+ These macros are all wrappers around the <CODE>echo</CODE> shell command.
+ @command{configure} scripts should rarely need to run <CODE>echo</CODE> directly
+ to print messages for the user. Using these macros makes it easy to
+ change how and when each kind of message is printed; such changes need
+ only be made to the macro definitions and all of the callers will change
+ automatically.
+
+
+ <P>
+ To diagnose static issues, i.e., when @command{autoconf} is run, see
+ section <A HREF="autoconf.html#SEC104">Reporting Messages</A>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MSG_CHECKING</B> <I>(<VAR>feature-description</VAR>)</I>
+ <DD><A NAME="IDX615"></A>
+ <A NAME="IDX616"></A>
+ Notify the user that @command{configure} 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>
+ This macro prints nothing if @command{configure} is run with the
+ @option{--quiet} or @option{--silent} option.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MSG_RESULT</B> <I>(<VAR>result-description</VAR>)</I>
+ <DD><A NAME="IDX617"></A>
+ <A NAME="IDX618"></A>
+ 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>
+ This macro prints nothing if @command{configure} is run with the
+ @option{--quiet} or @option{--silent} option.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MSG_NOTICE</B> <I>(<VAR>message</VAR>)</I>
+ <DD><A NAME="IDX619"></A>
+ <A NAME="IDX620"></A>
+ 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.,
+
+
+
+ <PRE>
+ AC_MSG_NOTICE([checking if stack overflow is detectable])
+ </PRE>
+
+ <P>
+ This macro prints nothing if @command{configure} is run with the
+ @option{--quiet} or @option{--silent} option.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MSG_ERROR</B> <I>(<VAR>error-description</VAR>, @ovar{exit-status})</I>
+ <DD><A NAME="IDX621"></A>
+ <A NAME="IDX622"></A>
+ Notify the user of an error that prevents @command{configure} from
+ completing. This macro prints an error message to the standard error
+ output and exits @command{configure} with <VAR>exit-status</VAR> (1 by default).
+ <VAR>error-description</VAR> should be something like <SAMP>`invalid value
+ $HOME for \$HOME'</SAMP>.
+
+
+ <P>
+ The <VAR>error-description</VAR> should start with a lower-case letter, and
+ "cannot" is preferred to "can't".
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MSG_WARN</B> <I>(<VAR>problem-description</VAR>)</I>
+ <DD><A NAME="IDX623"></A>
+ <A NAME="IDX624"></A>
+ Notify the @command{configure} user of a possible problem. This macro
+ prints the message to the standard error output; @command{configure}
+ 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>.
+ </DL>
+
+
+
+
+ <H1><A NAME="SEC87" HREF="autoconf_toc.html#TOC87">Programming in M4</A></H1>
+
+ <P>
+ Autoconf is written on top of two layers: <EM>M4sugar</EM>, which provides
+ convenient macros for pure M4 programming, and <EM>M4sh</EM>, which
+ provides macros dedicated to shell script generation.
+
+
+ <P>
+ As of this version of Autoconf, these two layers are still experimental,
+ and their interface might change in the future. As a matter of fact,
+ <EM>anything that is not documented must not be used</EM>.
+
+
+
+
+ <H2><A NAME="SEC88" HREF="autoconf_toc.html#TOC88">M4 Quotation</A></H2>
+ <P>
+ <A NAME="IDX625"></A>
+
+
+ <P>
+ The most common brokenness of existing macros is an improper quotation.
+ This section, which users of Autoconf can skip, but which macro writers
+ <EM>must</EM> read, first justifies the quotation scheme that was chosen
+ for Autoconf and then ends with a rule of thumb. Understanding the
+ former helps one to follow the latter.
+
+
+
+
+ <H3><A NAME="SEC89" HREF="autoconf_toc.html#TOC89">Active Characters</A></H3>
+
+ <P>
+ To fully understand where proper quotation is important, you first need
+ to know what are the special characters in Autoconf: <SAMP>`#'</SAMP> introduces
+ a comment inside which no macro expansion is performed, <SAMP>`,'</SAMP>
+ separates arguments, <SAMP>`['</SAMP> and <SAMP>`]'</SAMP> are the quotes themselves,
+ and finally <SAMP>`('</SAMP> and <SAMP>`)'</SAMP> (which <CODE>m4</CODE> tries to match by
+ pairs).
+
+
+ <P>
+ In order to understand the delicate case of macro calls, we first have
+ to present some obvious failures. Below they are "obvious-ified",
+ although you find them in real life, they are usually in disguise.
+
+
+ <P>
+ Comments, introduced by a hash and running up to the newline, are opaque
+ tokens to the top level: active characters are turned off, and there is
+ no macro expansion:
+
+
+
+ <PRE>
+ # define([def], ine)
+ =># define([def], ine)
+ </PRE>
+
+ <P>
+ Each time there can be a macro expansion, there is a quotation
+ expansion; i.e., one level of quotes is stripped:
+
+
+
+ <PRE>
+ int tab[10];
+ =>int tab10;
+ [int tab[10];]
+ =>int tab[10];
+ </PRE>
+
+ <P>
+ Without this in mind, the reader will try hopelessly to use her macro
+ <CODE>array</CODE>:
+
+
+
+ <PRE>
+ define([array], [int tab[10];])
+ array
+ =>int tab10;
+ [array]
+ =>array
+ </PRE>
+
+ <P>
+ How can you correctly output the intended results<A NAME="DOCF2" HREF="autoconf_foot.html#FOOT2">(2)</A>?
+
+
+
+
+ <H3><A NAME="SEC90" HREF="autoconf_toc.html#TOC90">One Macro Call</A></H3>
+
+ <P>
+ Let's proceed on the interaction between active characters and macros
+ with this small macro, which just returns its first argument:
+
+
+
+ <PRE>
+ define([car], [$1])
+ </PRE>
+
+ <P>
+ The two pairs of quotes above are not part of the arguments of
+ <CODE>define</CODE>; rather, they are understood by the top level when it
+ tries to find the arguments of <CODE>define</CODE>. Therefore, it is
+ equivalent to write:
+
+
+
+ <PRE>
+ define(car, $1)
+ </PRE>
+
+ <P>
+ But, while it is acceptable for a <TT>`configure.ac'</TT> to avoid unneeded
+ quotes, it is bad practice for Autoconf macros which must both be more
+ robust and also advocate perfect style.
+
+
+ <P>
+ At the top level, there are only two possible quotings: either you
+ quote or you don't:
+
+
+
+ <PRE>
+ car(foo, bar, baz)
+ =>foo
+ [car(foo, bar, baz)]
+ =>car(foo, bar, baz)
+ </PRE>
+
+ <P>
+ Let's pay attention to the special characters:
+
+
+
+ <PRE>
+ car(#)
+ error-->EOF in argument list
+ </PRE>
+
+ <P>
+ The closing parenthesis is hidden in the comment; with a hypothetical
+ quoting, the top level understood it this way:
+
+
+
+ <PRE>
+ car([#)]
+ </PRE>
+
+ <P>
+ Proper quotation, of course, fixes the problem:
+
+
+
+ <PRE>
+ car([#])
+ =>#
+ </PRE>
+
+ <P>
+ The reader will easily understand the following examples:
+
+
+
+ <PRE>
+ car(foo, bar)
+ =>foo
+ car([foo, bar])
+ =>foo, bar
+ car((foo, bar))
+ =>(foo, bar)
+ car([(foo], [bar)])
+ =>(foo
+ car([], [])
+ =>
+ car([[]], [[]])
+ =>[]
+ </PRE>
+
+ <P>
+ With this in mind, we can explore the cases where macros invoke
+ macros...
+
+
+
+
+ <H3><A NAME="SEC91" HREF="autoconf_toc.html#TOC91">Quotation and Nested Macros</A></H3>
+
+ <P>
+ The examples below use the following macros:
+
+
+
+ <PRE>
+ define([car], [$1])
+ define([active], [ACT, IVE])
+ define([array], [int tab[10]])
+ </PRE>
+
+ <P>
+ Each additional embedded macro call introduces other possible
+ interesting quotations:
+
+
+
+ <PRE>
+ car(active)
+ =>ACT
+ car([active])
+ =>ACT, IVE
+ car([[active]])
+ =>active
+ </PRE>
+
+ <P>
+ In the first case, the top level looks for the arguments of <CODE>car</CODE>,
+ and finds <SAMP>`active'</SAMP>. Because <CODE>m4</CODE> evaluates its arguments
+ before applying the macro, <SAMP>`active'</SAMP> is expanded, which results in:
+
+
+
+ <PRE>
+ car(ACT, IVE)
+ =>ACT
+ </PRE>
+
+ <P>
+ In the second case, the top level gives <SAMP>`active'</SAMP> as first and only
+ argument of <CODE>car</CODE>, which results in:
+
+
+
+ <PRE>
+ active
+ =>ACT, IVE
+ </PRE>
+
+ <P>
+ i.e., the argument is evaluated <EM>after</EM> the macro that invokes it.
+ In the third case, <CODE>car</CODE> receives <SAMP>`[active]'</SAMP>, which results in:
+
+
+
+ <PRE>
+ [active]
+ =>active
+ </PRE>
+
+ <P>
+ exactly as we already saw above.
+
+
+ <P>
+ The example above, applied to a more realistic example, gives:
+
+
+
+ <PRE>
+ car(int tab[10];)
+ =>int tab10;
+ car([int tab[10];])
+ =>int tab10;
+ car([[int tab[10];]])
+ =>int tab[10];
+ </PRE>
+
+ <P>
+ Huh? The first case is easily understood, but why is the second wrong,
+ and the third right? To understand that, you must know that after
+ <CODE>m4</CODE> expands a macro, the resulting text is immediately subjected
+ to macro expansion and quote removal. This means that the quote removal
+ occurs twice--first before the argument is passed to the <CODE>car</CODE>
+ macro, and second after the <CODE>car</CODE> macro expands to the first
+ argument.
+
+
+ <P>
+ As the author of the Autoconf macro <CODE>car</CODE>, you then consider it to
+ be incorrect that your users have to double-quote the arguments of
+ <CODE>car</CODE>, so you "fix" your macro. Let's call it <CODE>qar</CODE> for
+ quoted car:
+
+
+
+ <PRE>
+ define([qar], [[$1]])
+ </PRE>
+
+ <P>
+ and check that <CODE>qar</CODE> is properly fixed:
+
+
+
+ <PRE>
+ qar([int tab[10];])
+ =>int tab[10];
+ </PRE>
+
+ <P>
+ Ahhh! That's much better.
+
+
+ <P>
+ But note what you've done: now that the arguments are literal strings,
+ if the user wants to use the results of expansions as arguments, she has
+ to use an <EM>unquoted</EM> macro call:
+
+
+
+ <PRE>
+ qar(active)
+ =>ACT
+ </PRE>
+
+ <P>
+ where she wanted to reproduce what she used to do with <CODE>car</CODE>:
+
+
+
+ <PRE>
+ car([active])
+ =>ACT, IVE
+ </PRE>
+
+ <P>
+ Worse yet: she wants to use a macro that produces a set of <CODE>cpp</CODE>
+ macros:
+
+
+
+ <PRE>
+ define([my_includes], [#include <stdio.h>])
+ car([my_includes])
+ =>#include <stdio.h>
+ qar(my_includes)
+ error-->EOF in argument list
+ </PRE>
+
+ <P>
+ This macro, <CODE>qar</CODE>, because it double quotes its arguments, forces
+ its users to leave their macro calls unquoted, which is dangerous.
+ Commas and other active symbols are interpreted by <CODE>m4</CODE> before
+ they are given to the macro, often not in the way the users expect.
+ Also, because <CODE>qar</CODE> behaves differently from the other macros,
+ it's an exception that should be avoided in Autoconf.
+
+
+
+
+ <H3><A NAME="SEC92" HREF="autoconf_toc.html#TOC92"><CODE>changequote</CODE> is Evil</A></H3>
+
+ <P>
+ The temptation is often high to bypass proper quotation, in particular
+ when it's late at night. Then, many experienced Autoconf hackers
+ finally surrender to the dark side of the force and use the ultimate
+ weapon: <CODE>changequote</CODE>.
+
+
+ <P>
+ The M4 builtin <CODE>changequote</CODE> belongs to a set of primitives that
+ allow one to adjust the syntax of the language to adjust it to her
+ needs. For instance, by default M4 uses <SAMP>``'</SAMP> and <SAMP>`''</SAMP> as
+ quotes, but in the context of shell programming (and actually of most
+ programming languages), it's about the worst choice one can make:
+ because of strings and back quoted expression in shell (such as
+ <SAMP>`'this''</SAMP> and <SAMP>``that`'</SAMP>), because of literal characters in usual
+ programming language (as in <SAMP>`'0''</SAMP>), there are many unbalanced
+ <SAMP>``'</SAMP> and <SAMP>`''</SAMP>. Proper M4 quotation then becomes a nightmare, if
+ not impossible. In order to make M4 useful in such a context, its
+ designers have equipped it with <CODE>changequote</CODE>, which makes it
+ possible to chose another pair of quotes. M4sugar, M4sh, Autoconf, and
+ Autotest all have chosen to use <SAMP>`['</SAMP> and <SAMP>`]'</SAMP>. Not especially
+ because they are unlikely characters, but <EM>because they are
+ characters unlikely to be unbalanced</EM>.
+
+
+ <P>
+ There are other magic primitives, such as <CODE>changecom</CODE> to specify
+ what syntactic forms are comments (it is common to see
+ <SAMP>`changecom(<!--, -->)'</SAMP> when M4 is used to produce HTML pages),
+ <CODE>changeword</CODE> and <CODE>changesyntax</CODE> to change other syntactic
+ details (such as the character to denote the n-th argument, <SAMP>`$'</SAMP> by
+ default, the parenthesis around arguments etc.).
+
+
+ <P>
+ These primitives are really meant to make M4 more useful for specific
+ domains: they should be considered like command line options:
+ @option{--quotes}, @option{--comments}, @option{--words}, and
+ <CODE>--syntax</CODE>. Nevertheless, they are implemented as M4 builtins, as
+ it makes M4 libraries self contained (no need for additional options).
+
+
+ <P>
+ There lies the problem...
+
+
+ <P>
+ The problem is that it is then tempting to use them in the middle of an
+ M4 script, as opposed to its initialization. This, if not carefully
+ thought, can lead to disastrous effects: <EM>you are changing the
+ language in the middle of the execution</EM>. Changing and restoring the
+ syntax is often not enough: if you happened to invoke macros in between,
+ these macros will be lost, as the current syntax will probably not be
+ the one they were implemented with.
+
+
+
+
+ <H3><A NAME="SEC93" HREF="autoconf_toc.html#TOC93">Quadrigraphs</A></H3>
+ <P>
+ <A NAME="IDX626"></A>
+ <A NAME="IDX627"></A>
+ <A NAME="IDX628"></A>
+ <A NAME="IDX629"></A>
+ <A NAME="IDX630"></A>
+ <A NAME="IDX631"></A>
+
+
+ <P>
+ When writing an autoconf macro you may occasionally need to generate
+ special characters that are difficult to express with the standard
+ autoconf quoting rules. For example, you may need to output the regular
+ expression <SAMP>`[^[]'</SAMP>, which matches any character other than <SAMP>`['</SAMP>.
+ This expression contains unbalanced brackets so it cannot be put easily
+ into an M4 macro.
+
+
+ <P>
+ You can work around this problem by using one of the following
+ <EM>quadrigraphs</EM>:
+
+
+ <DL COMPACT>
+
+ <DT><SAMP>`@<:@'</SAMP>
+ <DD>
+ <SAMP>`['</SAMP>
+ <DT><SAMP>`@:>@'</SAMP>
+ <DD>
+ <SAMP>`]'</SAMP>
+ <DT><SAMP>`@S|@'</SAMP>
+ <DD>
+ <SAMP>`$'</SAMP>
+ <DT><SAMP>`@%:@'</SAMP>
+ <DD>
+ <SAMP>`#'</SAMP>
+ <DT><SAMP>`@&t@'</SAMP>
+ <DD>
+ Expands to nothing.
+ </DL>
+
+ <P>
+ Quadrigraphs are replaced at a late stage of the translation process,
+ after @command{m4} is run, so they do not get in the way of M4 quoting.
+ For example, the string <SAMP>`^@<:@'</SAMP>, independently of its quotation,
+ will appear as <SAMP>`^['</SAMP> in the output.
+
+
+ <P>
+ The empty quadrigraph can be used:
+
+
+
+ <UL>
+ <LI>to mark explicitly trailing spaces
+
+ Trailing spaces are smashed by @command{autom4te}. This is a feature.
+
+ <LI>to produce other quadrigraphs
+
+ For instance <SAMP>`@<@&t@:@'</SAMP> produces <SAMP>`@<:@'</SAMP>.
+
+ <LI>to escape <EM>occurrences</EM> of forbidden patterns
+
+ For instance you might want to mention <CODE>AC_FOO</CODE> is a comment, while
+ still being sure that @command{autom4te} will still catch unexpanded
+ <SAMP>`AC_*'</SAMP>. Then write <SAMP>`AC@&t@_FOO'</SAMP>.
+ </UL>
+
+ <P>
+ The name <SAMP>`@&t@'</SAMP> was suggested by Paul Eggert:
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ I should give some credit to the <SAMP>`@&t@'</SAMP> pun. The <SAMP>`&'</SAMP> is my
+ own invention, but the <SAMP>`t'</SAMP> came from the source code of the
+ ALGOL68C compiler, written by Steve Bourne (of Bourne shell fame),
+ and which used <SAMP>`mt'</SAMP> to denote the empty string. In C, it would
+ have looked like something like:
+
+
+
+ <PRE>
+ char const mt[] = "";
+ </PRE>
+
+ <P>
+ but of course the source code was written in Algol 68.
+
+
+ <P>
+ I don't know where he got <SAMP>`mt'</SAMP> from: it could have been his own
+ invention, and I suppose it could have been a common pun around the
+ Cambridge University computer lab at the time.
+ </BLOCKQUOTE>
+
+
+
+ <H3><A NAME="SEC94" HREF="autoconf_toc.html#TOC94">Quotation Rule Of Thumb</A></H3>
+
+ <P>
+ To conclude, the quotation rule of thumb is:
+
+
+ <P>
+ <EM>One pair of quotes per pair of parentheses.</EM>
+
+
+ <P>
+ Never over-quote, never under-quote, in particular in the definition of
+ macros. In the few places where the macros need to use brackets
+ (usually in C program text or regular expressions), properly quote
+ <EM>the arguments</EM>!
+
+
+ <P>
+ It is common to read Autoconf programs with snippets like:
+
+
+
+ <PRE>
+ AC_TRY_LINK(
+ changequote(<<, >>)dnl
+ <<#include <time.h>
+ #ifndef tzname /* For SGI. */
+ extern char *tzname[]; /* RS6000 and others reject char **tzname. */
+ #endif>>,
+ changequote([, ])dnl
+ [atoi (*tzname);], ac_cv_var_tzname=yes, ac_cv_var_tzname=no)
+ </PRE>
+
+ <P>
+ which is incredibly useless since <CODE>AC_TRY_LINK</CODE> is <EM>already</EM>
+ double quoting, so you just need:
+
+
+
+ <PRE>
+ AC_TRY_LINK(
+ [#include <time.h>
+ #ifndef tzname /* For SGI. */
+ extern char *tzname[]; /* RS6000 and others reject char **tzname. */
+ #endif],
+ [atoi (*tzname);],
+ [ac_cv_var_tzname=yes],
+ [ac_cv_var_tzname=no])
+ </PRE>
+
+ <P>
+ The M4-fluent reader will note that these two examples are rigorously
+ equivalent, since <CODE>m4</CODE> swallows both the <SAMP>`changequote(<<, >>)'</SAMP>
+ and <SAMP>`<<'</SAMP> <SAMP>`>>'</SAMP> when it <EM>collects</EM> the arguments: these
+ quotes are not part of the arguments!
+
+
+ <P>
+ Simplified, the example above is just doing this:
+
+
+
+ <PRE>
+ changequote(<<, >>)dnl
+ <<[]>>
+ changequote([, ])dnl
+ </PRE>
+
+ <P>
+ instead of simply:
+
+
+
+ <PRE>
+ [[]]
+ </PRE>
+
+ <P>
+ With macros that do not double quote their arguments (which is the
+ rule), double-quote the (risky) literals:
+
+
+
+ <PRE>
+ AC_LINK_IFELSE([AC_LANG_PROGRAM(
+ [[#include <time.h>
+ #ifndef tzname /* For SGI. */
+ extern char *tzname[]; /* RS6000 and others reject char **tzname. */
+ #endif]],
+ [atoi (*tzname);])],
+ [ac_cv_var_tzname=yes],
+ [ac_cv_var_tzname=no])
+ </PRE>
+
+ <P>
+ See See section <A HREF="autoconf.html#SEC93">Quadrigraphs</A>, for what to do if you run into a hopeless case
+ where quoting does not suffice.
+
+
+ <P>
+ When you create a @command{configure} script using newly written macros,
+ examine it carefully to check whether you need to add more quotes in
+ your macros. If one or more words have disappeared in the <CODE>m4</CODE>
+ output, you need more quotes. When in doubt, quote.
+
+
+ <P>
+ However, it's also possible to put on too many layers of quotes. If
+ this happens, the resulting @command{configure} script will contain
+ unexpanded macros. The @command{autoconf} program checks for this problem
+ by doing <SAMP>`grep AC_ configure'</SAMP>.
+
+
+
+
+ <H2><A NAME="SEC95" HREF="autoconf_toc.html#TOC95">Invoking @command{autom4te}</A></H2>
+
+ <P>
+ The Autoconf suite, including M4sugar, M4sh, and Autotest in addition to
+ Autoconf per se, heavily rely on M4. All these different uses revealed
+ common needs factored into a layer over @command{m4}:
+ @command{autom4te}<A NAME="DOCF3" HREF="autoconf_foot.html#FOOT3">(3)</A>.
+
+
+ <P>
+ @command{autom4te} should basically considered as a replacement of
+ @command{m4} itself. In particular, its handling of command line
+ arguments is modeled after M4's:
+
+
+
+ <PRE>
+ autom4te <VAR>options</VAR> <VAR>files</VAR>
+ </PRE>
+
+ <P>
+ where the <VAR>files</VAR> are directly passed to @command{m4}. In addition
+ to the regular expansion, it handles the replacement of the quadrigraphs
+ (see section <A HREF="autoconf.html#SEC93">Quadrigraphs</A>), and of <SAMP>`__oline__'</SAMP>, the current line in the
+ output. It supports an extended syntax for the <VAR>files</VAR>:
+
+
+ <DL COMPACT>
+
+ <DT><TT>`<VAR>file</VAR>.m4f'</TT>
+ <DD>
+ This file is an M4 frozen file. Note that <EM>all the previous files
+ are ignored</EM>. See the option @option{--melt} for the rationale.
+
+ <DT><TT>`<VAR>file</VAR>?'</TT>
+ <DD>
+ If found in the library path, the <VAR>file</VAR> is included for expansion,
+ otherwise it is ignored instead of triggering a failure.
+ </DL>
+
+ <P>
+ Of course, it supports the Autoconf common subset of options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+
+ <DT>@option{--verbose}
+ <DD>
+ <DT>@option{-v}
+ <DD>
+ Report processing steps.
+
+ <DT>@option{--debug}
+ <DD>
+ <DT>@option{-d}
+ <DD>
+ Don't remove the temporary files and be even more verbose.
+
+ <DT>@option{--include=<VAR>dir</VAR>}
+ <DD>
+ <DT>@option{-I <VAR>dir</VAR>}
+ <DD>
+ Also look for input files in <VAR>dir</VAR>. Multiple invocations
+ accumulate. Contrary to M4 but in agreement with common sense,
+ directories are browsed from last to first.
+
+ <DT>@option{--output=<VAR>file</VAR>}
+ <DD>
+ <DT>@option{-o <VAR>file</VAR>}
+ <DD>
+ Save output (script or trace) to <VAR>file</VAR>. The file @option{-} stands
+ for the standard output.
+ </DL>
+
+ <P>
+ As an extension of @command{m4}, it includes the following options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--warnings=<VAR>category</VAR>}
+ <DD>
+ <DT>@option{-W <VAR>category</VAR>}
+ <DD>
+ <A NAME="IDX632"></A>
+ Report the warnings related to <VAR>category</VAR> (which can actually be a
+ comma separated list). See section <A HREF="autoconf.html#SEC104">Reporting Messages</A>, macro
+ <CODE>AC_DIAGNOSE</CODE>, for a comprehensive list of categories. Special
+ values include:
+
+ <DL COMPACT>
+
+ <DT><SAMP>`all'</SAMP>
+ <DD>
+ report all the warnings
+
+ <DT><SAMP>`none'</SAMP>
+ <DD>
+ report none
+
+ <DT><SAMP>`error'</SAMP>
+ <DD>
+ treats warnings as errors
+
+ <DT><SAMP>`no-<VAR>category</VAR>'</SAMP>
+ <DD>
+ disable warnings falling into <VAR>category</VAR>
+ </DL>
+
+ Warnings about <SAMP>`syntax'</SAMP> are enabled by default, and the environment
+ variable <CODE>WARNINGS</CODE>, a comma separated list of categories, is
+ honored. @command{autom4te -W <VAR>category</VAR>} will actually
+ behave as if you had run:
+
+
+ <PRE>
+ autom4te --warnings=syntax,$WARNINGS,<VAR>category</VAR>
+ </PRE>
+
+ If you want to disable @command{autom4te}'s defaults and
+ <CODE>WARNINGS</CODE>, but (for example) enable the warnings about obsolete
+ constructs, you would use @option{-W none,obsolete}.
+
+ <A NAME="IDX633"></A>
+ <A NAME="IDX634"></A>
+ @command{autom4te} displays a back trace for errors, but not for
+ warnings; if you want them, just pass @option{-W error}. For instance,
+ on this <TT>`configure.ac'</TT>:
+
+
+ <PRE>
+ AC_DEFUN([INNER],
+ [AC_TRY_RUN([exit (0)])])
+
+ AC_DEFUN([OUTER],
+ [INNER])
+
+ AC_INIT
+ OUTER
+ </PRE>
+
+ you get:
+
+
+ <PRE>
+ $ <KBD>autom4te -l autoconf -Wcross</KBD>
+ configure.ac:8: warning: AC_TRY_RUN called without default \
+ to allow cross compiling
+ $ <KBD>autom4te -l autoconf -Wcross,error</KBD>
+ configure.ac:8: error: AC_TRY_RUN called without default \
+ to allow cross compiling
+ acgeneral.m4:3044: AC_TRY_RUN is expanded from...
+ configure.ac:2: INNER is expanded from...
+ configure.ac:5: OUTER is expanded from...
+ configure.ac:8: the top level
+ </PRE>
+
+ <DT>@option{--melt}
+ <DD>
+ <DT>@option{-m}
+ <DD>
+ Do not use frozen files. Any argument <CODE><VAR>file</VAR>.m4f</CODE> will be
+ replaced with <CODE><VAR>file</VAR>.m4</CODE>. This helps tracing the macros which
+ are executed only when the files are frozen, typically
+ <CODE>m4_define</CODE>. For instance, running:
+
+
+ <PRE>
+ autom4te --melt 1.m4 2.m4f 3.m4 4.m4f input.m4
+ </PRE>
+
+ is roughly equivalent to running:
+
+
+ <PRE>
+ m4 1.m4 2.m4 3.m4 4.m4 input.m4
+ </PRE>
+
+ while
+
+
+ <PRE>
+ autom4te 1.m4 2.m4f 3.m4 4.m4f input.m4
+ </PRE>
+
+ is equivalent to:
+
+
+ <PRE>
+ m4 --reload-state=4.m4f input.m4
+ </PRE>
+
+ <DT>@option{--freeze}
+ <DD>
+ <DT>@option{-f}
+ <DD>
+ Produce a frozen state file. @command{autom4te} freezing is stricter
+ than M4's: it must produce no warnings, and no output other than empty
+ lines (a line with white spaces is <EM>not</EM> empty) and comments
+ (starting with <SAMP>`#'</SAMP>). Please, note that contrary to @command{m4},
+ this options takes no argument:
+
+
+ <PRE>
+ autom4te 1.m4 2.m4 3.m4 --freeze --output=3.m4f
+ </PRE>
+
+ corresponds to
+
+
+ <PRE>
+ m4 1.m4 2.m4 3.m4 --freeze-state=3.m4f
+ </PRE>
+
+ <DT>@option{--mode=<VAR>octal-mode</VAR>}
+ <DD>
+ <DT>@option{-m <VAR>octal-mode</VAR>}
+ <DD>
+ Set the mode of the non traces output to <VAR>octal-mode</VAR>. By default,
+ <SAMP>`0666'</SAMP>.
+ </DL>
+
+ <P>
+ <A NAME="IDX635"></A>
+ As another additional feature over @command{m4}, @command{autom4te}
+ caches its results. GNU M4 is able to produce a regular output and
+ traces at the same time. Traces are heavily used in the GNU Build
+ System: @command{autoheader} uses them to build <TT>`config.h.in'</TT>,
+ @command{autoreconf} to determine what GNU Build System components are
+ used, @command{automake} to "parse" <TT>`configure.ac'</TT> etc. To save
+ the long runs of @command{m4}, traces are cached while performing
+ regular expansion, and conversely. This cache is (actually, the caches
+ are) stored in the directory <TT>`autom4te.cache'</TT>. <EM>It can safely
+ be removed</EM> at any moment (especially if for some reason
+ @command{autom4te} considers it is trashed).
+
+
+ <DL COMPACT>
+
+ <DT>@option{--force}
+ <DD>
+ <DT>@option{-f}
+ <DD>
+ Do not consider the cache (but update it anyway).
+ </DL>
+
+ <P>
+ Because traces are so important to the GNU Build System,
+ @command{autom4te} provides high level tracing features as compared to
+ M4, and helps exploiting the cache:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--trace=<VAR>macro</VAR>[:<VAR>format</VAR>]}
+ <DD>
+ <DT>@option{-t <VAR>macro</VAR>[:<VAR>format</VAR>]}
+ <DD>
+ Trace the invocations to <VAR>macro</VAR> according to the <VAR>format</VAR>.
+ Multiple @option{--trace} arguments can be used to list several macros.
+ Multiple @option{--trace} arguments for a single macro are not
+ cumulative; instead, you should just make <VAR>format</VAR> as long as
+ needed.
+
+ The <VAR>format</VAR> is a regular string, with newlines if desired, and
+ several special escape codes. It defaults to <SAMP>`$f:$l:$n:$%'</SAMP>. It can
+ use the following special escapes:
+
+ <DL COMPACT>
+
+ <DT><SAMP>`$$'</SAMP>
+ <DD>
+ The character <SAMP>`$'</SAMP>.
+
+ <DT><SAMP>`$f'</SAMP>
+ <DD>
+ The filename from which <VAR>macro</VAR> is called.
+
+ <DT><SAMP>`$l'</SAMP>
+ <DD>
+ The line number from which <VAR>macro</VAR> is called.
+
+ <DT><SAMP>`$d'</SAMP>
+ <DD>
+ The depth of the <VAR>macro</VAR> call. This is an M4 technical detail that
+ you probably don't want to know about.
+
+ <DT><SAMP>`$n'</SAMP>
+ <DD>
+ The name of the <VAR>macro</VAR>.
+
+ <DT><SAMP>`$<VAR>num</VAR>'</SAMP>
+ <DD>
+ The <VAR>num</VAR>th argument of the call to <VAR>macro</VAR>.
+
+ <DT><SAMP>`$@'</SAMP>
+ <DD>
+ <DT><SAMP>`$<VAR>sep</VAR>@'</SAMP>
+ <DD>
+ <DT><SAMP>`${<VAR>separator</VAR>}@'</SAMP>
+ <DD>
+ All the arguments passed to <VAR>macro</VAR>, separated by the character
+ <VAR>sep</VAR> or the string <VAR>separator</VAR> (<SAMP>`,'</SAMP> by default). Each
+ argument is quoted, i.e. enclosed in a pair of square brackets.
+
+ <DT><SAMP>`$*'</SAMP>
+ <DD>
+ <DT><SAMP>`$<VAR>sep</VAR>*'</SAMP>
+ <DD>
+ <DT><SAMP>`${<VAR>separator</VAR>}*'</SAMP>
+ <DD>
+ As above, but the arguments are not quoted.
+
+ <DT><SAMP>`$%'</SAMP>
+ <DD>
+ <DT><SAMP>`$<VAR>sep</VAR>%'</SAMP>
+ <DD>
+ <DT><SAMP>`${<VAR>separator</VAR>}%'</SAMP>
+ <DD>
+ As above, but the arguments are not quoted, all new line characters in
+ the arguments are smashed, and the default separator is <SAMP>`:'</SAMP>.
+
+ The escape <SAMP>`$%'</SAMP> produces single-line trace outputs (unless you put
+ newlines in the <SAMP>`separator'</SAMP>), while <SAMP>`$@'</SAMP> and <SAMP>`$*'</SAMP> do
+ not.
+ </DL>
+
+ See section <A HREF="autoconf.html#SEC13">Using @command{autoconf} to Create @command{configure}</A>, for examples of trace uses.
+
+ <DT>@option{--preselect=<VAR>macro</VAR>}
+ <DD>
+ <DT>@option{-p <VAR>macro</VAR>}
+ <DD>
+ Cache the traces of <VAR>macro</VAR>, but do not enable traces. This is
+ especially important to save cpu cycles in the future. For instance,
+ when invoked, @command{autoconf} preselects all the macros that
+ @command{autoheader}, <CODE>automake</CODE>, <CODE>autoreconf</CODE> etc. will
+ trace, so that running @command{m4} is not needed to trace them: the
+ cache suffices. This results in a huge speed-up.
+ </DL>
+
+ <P>
+ <A NAME="IDX636"></A>
+ Finally, @command{autom4te} introduces the concept of @dfn{Autom4te
+ libraries}. They consists in a powerful yet extremely simple feature:
+ sets of combined command line arguments:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--language=<VAR>language</VAR>}
+ <DD>
+ <DT>@option{-l =<VAR>language</VAR>}
+ <DD>
+ Use the <VAR>language</VAR> Autom4te library. Current languages include:
+
+ <DL COMPACT>
+
+ <DT><CODE>M4sugar</CODE>
+ <DD>
+ create M4sugar output.
+
+ <DT><CODE>M4sh</CODE>
+ <DD>
+ create M4sh executable shell scripts.
+
+ <DT><CODE>Autotest</CODE>
+ <DD>
+ create Autotest executable test suites.
+
+ <DT><CODE>Autoconf</CODE>
+ <DD>
+ create Autoconf executable configure scripts.
+ </DL>
+ </DL>
+
+ <P>
+ <A NAME="IDX637"></A>
+ As an example, if Autoconf is installed in its default location,
+ <TT>`/usr/local'</TT>, running <SAMP>`autom4te -l m4sugar foo.m4'</SAMP> is strictly
+ equivalent to running <SAMP>`autom4te --include /usr/local/share/autoconf
+ m4sugar/m4sugar.m4f --warning syntax foo.m4'</SAMP>. Recursive expansion
+ applies: running <SAMP>`autom4te -l m4sh foo.m4'</SAMP>, is the same as
+ <SAMP>`autom4te --language M4sugar m4sugar/m4sh.m4f foo.m4'</SAMP>, i.e.,
+ <SAMP>`autom4te --include /usr/local/share/autoconf m4sugar/m4sugar.m4f
+ m4sugar/m4sh.m4f --mode 777 foo.m4'</SAMP>. The definition of the languages is
+ stored in <TT>`autom4te.cfg'</TT>.
+
+
+
+
+ <H2><A NAME="SEC96" HREF="autoconf_toc.html#TOC96">Programming in M4sugar</A></H2>
+
+ <P>
+ <A NAME="IDX638"></A>
+ M4 by itself provides only a small, but sufficient, set of all-purpose
+ macros. M4sugar introduces additional generic macros. Its name was
+ coined by Lars J. Aas: "Readability And Greater Understanding Stands 4
+ M4sugar".
+
+
+
+
+ <H3><A NAME="SEC97" HREF="autoconf_toc.html#TOC97">Redefined M4 Macros</A></H3>
+
+ <P>
+ With a few exceptions, all the M4 native macros are moved in the
+ <SAMP>`m4_'</SAMP> pseudo-namespace, e.g., M4sugar renames <CODE>define</CODE> as
+ <CODE>m4_define</CODE> etc.
+
+
+ <P>
+ Some M4 macros are redefined, and are slightly incompatible with their
+ native equivalent.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>dnl</B>
+ <DD><A NAME="IDX639"></A>
+ <A NAME="IDX640"></A>
+ This macro kept its original name: no <CODE>m4_dnl</CODE> is defined.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_defn</B> <I>(<VAR>macro</VAR>)</I>
+ <DD><A NAME="IDX641"></A>
+ <A NAME="IDX642"></A>
+ Contrary to the M4 builtin, this macro fails if <VAR>macro</VAR> is not
+ defined. See <CODE>m4_undefine</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_exit</B> <I>(<VAR>exit-status</VAR>)</I>
+ <DD><A NAME="IDX643"></A>
+ <A NAME="IDX644"></A>
+ This macro corresponds to <CODE>m4exit</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_if</B> <I>(<VAR>comment</VAR>)</I>
+ <DD><A NAME="IDX645"></A>
+ <DT><U>Macro:</U> <B>m4_if</B> <I>(<VAR>string-1</VAR>, <VAR>string-2</VAR>, <VAR>equal</VAR>, @ovar{not-equal})</I>
+ <DD><A NAME="IDX646"></A>
+ <DT><U>Macro:</U> <B>m4_if</B> <I>(<VAR>string-1</VAR>, <VAR>string-2</VAR>, <VAR>equal</VAR>, ...)</I>
+ <DD><A NAME="IDX647"></A>
+ <A NAME="IDX648"></A>
+ This macro corresponds to <CODE>ifelse</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_undefine</B> <I>(<VAR>macro</VAR>)</I>
+ <DD><A NAME="IDX649"></A>
+ <A NAME="IDX650"></A>
+ Contrary to the M4 builtin, this macro fails if <VAR>macro</VAR> is not
+ defined. Use
+
+
+
+ <PRE>
+ m4_ifdef([<VAR>macro</VAR>], [m4_undefine([<VAR>macro</VAR>])])
+ </PRE>
+
+ <P>
+ to recover the behavior of the builtin.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_bpatsubst</B> <I>(<VAR>string</VAR>, <VAR>regexp</VAR>, @ovar{replacement})</I>
+ <DD><A NAME="IDX651"></A>
+ <A NAME="IDX652"></A>
+ This macro corresponds to <CODE>patsubst</CODE>. The name <CODE>m4_patsubst</CODE>
+ is kept for future versions of M4sh, on top of GNU M4 which will
+ provide extended regular expression syntax via <CODE>epatsubst</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_popdef</B> <I>(<VAR>macro</VAR>)</I>
+ <DD><A NAME="IDX653"></A>
+ <A NAME="IDX654"></A>
+ Contrary to the M4 builtin, this macro fails if <VAR>macro</VAR> is not
+ defined. See <CODE>m4_undefine</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_bregexp</B> <I>(<VAR>string</VAR>, <VAR>regexp</VAR>, @ovar{replacement})</I>
+ <DD><A NAME="IDX655"></A>
+ <A NAME="IDX656"></A>
+ This macro corresponds to <CODE>regexp</CODE>. The name <CODE>m4_regexp</CODE>
+ is kept for future versions of M4sh, on top of GNU M4 which will
+ provide extended regular expression syntax via <CODE>eregexp</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_wrap</B> <I>(<VAR>text</VAR>)</I>
+ <DD><A NAME="IDX657"></A>
+ <A NAME="IDX658"></A>
+ This macro corresponds to <CODE>m4wrap</CODE>.
+
+
+ <P>
+ You are encouraged to end <VAR>text</VAR> with <SAMP>`[]'</SAMP>, so that there are
+ no risks that two consecutive invocations of <CODE>m4_wrap</CODE> result in an
+ unexpected pasting of tokens, as in
+
+
+
+ <PRE>
+ m4_define([foo], [Foo])
+ m4_define([bar], [Bar])
+ m4_define([foobar], [FOOBAR])
+ m4_wrap([bar])
+ m4_wrap([foo])
+ =>FOOBAR
+ </PRE>
+
+ </DL>
+
+
+
+ <H3><A NAME="SEC98" HREF="autoconf_toc.html#TOC98">Evaluation Macros</A></H3>
+
+ <P>
+ The following macros give some control over the order of the evaluation
+ by adding or removing levels of quotes. They are meant for hard core M4
+ programmers.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_dquote</B> <I>(<VAR>arg1</VAR>, ...)</I>
+ <DD><A NAME="IDX659"></A>
+ <A NAME="IDX660"></A>
+ Return the arguments as a quoted list of quoted arguments.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_quote</B> <I>(<VAR>arg1</VAR>, ...)</I>
+ <DD><A NAME="IDX661"></A>
+ <A NAME="IDX662"></A>
+ Return the arguments as a single entity, i.e., wrap them into a pair of
+ quotes.
+ </DL>
+
+
+ <P>
+ The following example aims at emphasing the difference between (i), not
+ using these macros, (ii), using <CODE>m4_quote</CODE>, and (iii), using
+ <CODE>m4_dquote</CODE>.
+
+
+
+ <PRE>
+ $ <KBD>cat example.m4</KBD>
+ # Over quote, so that quotes are visible.
+ m4_define([show], [$[]1 = [$1], $[]@ = [$@]])
+ m4_divert(0)dnl
+ show(a, b)
+ show(m4_quote(a, b))
+ show(m4_dquote(a, b))
+ $ <KBD>autom4te -l m4sugar example.m4</KBD>
+ $1 = a, $@ = [a],[b]
+ $1 = a,b, $@ = [a,b]
+ $1 = [a],[b], $@ = [[a],[b]]
+ </PRE>
+
+
+
+ <H3><A NAME="SEC99" HREF="autoconf_toc.html#TOC99">Forbidden Patterns</A></H3>
+
+ <P>
+ M4sugar provides a means to define suspicious patterns, patterns
+ describing tokens which should not be found in the output. For
+ instance, if an Autoconf <TT>`configure'</TT> script includes tokens such as
+ <SAMP>`AC_DEFINE'</SAMP>, or <SAMP>`dnl'</SAMP>, then most probably something went
+ wrong (typically a macro was not evaluated because of over quotation).
+
+
+ <P>
+ M4sugar forbids all the tokens matching <SAMP>`^m4_'</SAMP> and <SAMP>`^dnl$'</SAMP>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_pattern_forbid</B> <I>(<VAR>pattern</VAR>)</I>
+ <DD><A NAME="IDX663"></A>
+ <A NAME="IDX664"></A>
+ Declare 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 makes sense to
+ the author of this documentation, as <SAMP>`#'</SAMP>-comments should document
+ the output, not the input, documented vy <SAMP>`dnl'</SAMP>-comments).
+ </DL>
+
+
+ <P>
+ Of course, you might encounter exceptions to these generic rules, for
+ instance you might have to refer to <SAMP>`$m4_flags'</SAMP>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>m4_pattern_allow</B> <I>(<VAR>pattern</VAR>)</I>
+ <DD><A NAME="IDX665"></A>
+ <A NAME="IDX666"></A>
+ Any token matching <VAR>pattern</VAR> is allowed, including if it matches an
+ <CODE>m4_pattern_forbid</CODE> pattern.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC100" HREF="autoconf_toc.html#TOC100">Programming in M4sh</A></H2>
+
+ <P>
+ M4sh provides portable alternatives for some common shell constructs
+ that unfortunately are not portable in practice.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AS_DIRNAME</B> <I>(<VAR>pathname</VAR>)</I>
+ <DD><A NAME="IDX667"></A>
+ <A NAME="IDX668"></A>
+ Return the directory portion of <VAR>pathname</VAR>, using the algorithm
+ required by POSIX. See section <A HREF="autoconf.html#SEC119">Limitations of Usual Tools</A>, for more
+ details about what this returns and why it is more portable than the
+ @command{dirname} command.
+ </DL>
+
+
+
+
+ <H1><A NAME="SEC101" HREF="autoconf_toc.html#TOC101">Writing Autoconf Macros</A></H1>
+
+ <P>
+ When you write a feature test that could be applicable to more than one
+ software package, the best thing to do is encapsulate it in a new macro.
+ Here are some instructions and guidelines for writing Autoconf macros.
+
+
+
+
+ <H2><A NAME="SEC102" HREF="autoconf_toc.html#TOC102">Macro Definitions</A></H2>
+
+ <P>
+ <A NAME="IDX669"></A>
+ Autoconf macros are defined using the <CODE>AC_DEFUN</CODE> macro, which is
+ similar to the M4 builtin <CODE>m4_define</CODE> macro. 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 (see section <A HREF="autoconf.html#SEC106">Prerequisite Macros</A>).
+
+
+ <P>
+ An Autoconf macro definition looks like this:
+
+
+
+ <PRE>
+ AC_DEFUN(<VAR>macro-name</VAR>, <VAR>macro-body</VAR>)
+ </PRE>
+
+ <P>
+ You can refer to any arguments passed to the macro as <SAMP>`$1'</SAMP>,
+ <SAMP>`$2'</SAMP>, etc. See section `How to define new macros' in <CITE>GNU m4</CITE>, for more complete information on writing M4 macros.
+
+
+ <P>
+ Be sure to properly quote both the <VAR>macro-body</VAR> <EM>and</EM> the
+ <VAR>macro-name</VAR> to avoid any problems if the macro happens to have
+ been previously defined.
+
+
+ <P>
+ Each macro should have a header comment that gives its prototype, and a
+ brief description. When arguments have default values, display them in
+ the prototype. For example:
+
+
+
+ <PRE>
+ # AC_MSG_ERROR(ERROR, [EXIT-STATUS = 1])
+ # --------------------------------------
+ m4_define([AC_MSG_ERROR],
+ [{ _AC_ECHO([configure: error: $1], 2); exit m4_default([$2], 1); }])
+ </PRE>
+
+ <P>
+ Comments about the macro should be left in the header comment. Most
+ other comments will make their way into <TT>`configure'</TT>, so just keep
+ using <SAMP>`#'</SAMP> to introduce comments.
+
+
+ <P>
+ <A NAME="IDX670"></A>
+ If you have some very special comments about pure M4 code, comments
+ that make no sense in <TT>`configure'</TT> and in the header comment, then
+ use the builtin <CODE>dnl</CODE>: it causes <CODE>m4</CODE> to discard the text
+ through the next newline.
+
+
+ <P>
+ Keep in mind that <CODE>dnl</CODE> is rarely needed to introduce comments;
+ <CODE>dnl</CODE> is more useful to get rid of the newlines following macros
+ that produce no output, such as <CODE>AC_REQUIRE</CODE>.
+
+
+
+
+ <H2><A NAME="SEC103" HREF="autoconf_toc.html#TOC103">Macro Names</A></H2>
+
+ <P>
+ All of the Autoconf macros have all-uppercase names starting with
+ <SAMP>`AC_'</SAMP> to prevent them from accidentally conflicting with other
+ text. All shell variables that they use for internal purposes have
+ mostly-lowercase names starting with <SAMP>`ac_'</SAMP>. To ensure that your
+ macros don't conflict with present or future Autoconf macros, you should
+ prefix your own macro names and any shell variables they use with some
+ other sequence. Possibilities include your initials, or an abbreviation
+ for the name of your organization or software package.
+
+
+ <P>
+ Most of the Autoconf macros' names follow a structured naming convention
+ that indicates the kind of feature check by the name. The macro names
+ consist of several words, separated by underscores, going from most
+ general to most specific. The names of their cache variables use the
+ same convention (see section <A HREF="autoconf.html#SEC83">Cache Variable Names</A>, for more information on
+ them).
+
+
+ <P>
+ The first word of the name after <SAMP>`AC_'</SAMP> usually tells the category
+ of feature being tested. Here are the categories used in Autoconf for
+ specific test macros, the kind of macro that you are more likely to
+ write. They are also used for cache variables, in all-lowercase. Use
+ them where applicable; where they're not, invent your own categories.
+
+
+ <DL COMPACT>
+
+ <DT><CODE>C</CODE>
+ <DD>
+ C language builtin features.
+ <DT><CODE>DECL</CODE>
+ <DD>
+ Declarations of C variables in header files.
+ <DT><CODE>FUNC</CODE>
+ <DD>
+ Functions in libraries.
+ <DT><CODE>GROUP</CODE>
+ <DD>
+ UNIX group owners of files.
+ <DT><CODE>HEADER</CODE>
+ <DD>
+ Header files.
+ <DT><CODE>LIB</CODE>
+ <DD>
+ C libraries.
+ <DT><CODE>PATH</CODE>
+ <DD>
+ The full path names to files, including programs.
+ <DT><CODE>PROG</CODE>
+ <DD>
+ The base names of programs.
+ <DT><CODE>MEMBER</CODE>
+ <DD>
+ Members of aggregates.
+ <DT><CODE>SYS</CODE>
+ <DD>
+ Operating system features.
+ <DT><CODE>TYPE</CODE>
+ <DD>
+ C builtin or declared types.
+ <DT><CODE>VAR</CODE>
+ <DD>
+ C variables in libraries.
+ </DL>
+
+ <P>
+ After the category comes the name of the particular feature being
+ tested. Any further words in the macro name indicate particular aspects
+ of the feature. For example, <CODE>AC_FUNC_UTIME_NULL</CODE> checks the
+ behavior of the <CODE>utime</CODE> function when called with a <CODE>NULL</CODE>
+ pointer.
+
+
+ <P>
+ An internal macro should have a name that starts with an underscore;
+ Autoconf internals should therefore start with <SAMP>`_AC_'</SAMP>.
+ Additionally, a macro that is an internal subroutine of another macro
+ should have a name that starts with an underscore and the name of that
+ other macro, followed by one or more words saying what the internal
+ macro does. For example, <CODE>AC_PATH_X</CODE> has internal macros
+ <CODE>_AC_PATH_X_XMKMF</CODE> and <CODE>_AC_PATH_X_DIRECT</CODE>.
+
+
+
+
+ <H2><A NAME="SEC104" HREF="autoconf_toc.html#TOC104">Reporting Messages</A></H2>
+ <P>
+ <A NAME="IDX671"></A>
+
+
+ <P>
+ When macros statically diagnose abnormal situations, benign or fatal,
+ they should report them using these macros. For dynamic issues, i.e.,
+ when @command{configure} is run, see section <A HREF="autoconf.html#SEC86">Printing Messages</A>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_DIAGNOSE</B> <I>(<VAR>category</VAR>, <VAR>message</VAR>)</I>
+ <DD><A NAME="IDX672"></A>
+ <A NAME="IDX673"></A>
+ Report <VAR>message</VAR> as a warning (or as an error if requested by the
+ user) if it falls into the <VAR>category</VAR>. You are encouraged to use
+ standard categories, which currently include:
+
+
+ <DL COMPACT>
+
+ <DT><SAMP>`all'</SAMP>
+ <DD>
+ messages that don't fall into one of the following category. Use of an
+ empty <VAR>category</VAR> is equivalent.
+
+ <DT><SAMP>`cross'</SAMP>
+ <DD>
+ related to cross compilation issues.
+
+ <DT><SAMP>`obsolete'</SAMP>
+ <DD>
+ use of an obsolete construct.
+
+ <DT><SAMP>`syntax'</SAMP>
+ <DD>
+ dubious syntactic constructs, incorrectly ordered macro calls.
+ </DL>
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_WARNING</B> <I>(<VAR>message</VAR>)</I>
+ <DD><A NAME="IDX674"></A>
+ <A NAME="IDX675"></A>
+ Equivalent to <SAMP>`AC_DIAGNOSE([syntax], <VAR>message</VAR>)'</SAMP>, but you are
+ strongly encouraged to use a finer grained category.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FATAL</B> <I>(<VAR>message</VAR>)</I>
+ <DD><A NAME="IDX676"></A>
+ <A NAME="IDX677"></A>
+ Report a severe error <VAR>message</VAR>, and have @command{autoconf} die.
+ </DL>
+
+
+ <P>
+ When the user runs <SAMP>`autoconf -W error'</SAMP>, warnings from
+ <CODE>AC_DIAGNOSE</CODE> and <CODE>AC_WARNING</CODE> are reported as error, see
+ section <A HREF="autoconf.html#SEC13">Using @command{autoconf} to Create @command{configure}</A>.
+
+
+
+
+ <H2><A NAME="SEC105" HREF="autoconf_toc.html#TOC105">Dependencies Between Macros</A></H2>
+
+ <P>
+ Some Autoconf macros depend on other macros having been called first in
+ order to work correctly. Autoconf provides a way to ensure that certain
+ macros are called if needed and a way to warn the user if macros are
+ called in an order that might cause incorrect operation.
+
+
+
+
+ <H3><A NAME="SEC106" HREF="autoconf_toc.html#TOC106">Prerequisite Macros</A></H3>
+
+ <P>
+ A macro that you write might need to use values that have previously
+ been computed by other macros. For example, <CODE>AC_DECL_YYTEXT</CODE>
+ examines the output of <CODE>flex</CODE> or <CODE>lex</CODE>, so it depends on
+ <CODE>AC_PROG_LEX</CODE> having been called first to set the shell variable
+ <CODE>LEX</CODE>.
+
+
+ <P>
+ Rather than forcing the user of the macros to keep track of the
+ dependencies between them, you can use the <CODE>AC_REQUIRE</CODE> macro to do
+ it automatically. <CODE>AC_REQUIRE</CODE> can ensure that a macro is only
+ called if it is needed, and only called once.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_REQUIRE</B> <I>(<VAR>macro-name</VAR>)</I>
+ <DD><A NAME="IDX678"></A>
+ <A NAME="IDX679"></A>
+ 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>
+ <CODE>AC_REQUIRE</CODE> must be used inside an <CODE>AC_DEFUN</CODE>'d macro; it
+ must not be called from the top level.
+ </DL>
+
+
+ <P>
+ <CODE>AC_REQUIRE</CODE> is often misunderstood. It really implements
+ dependencies between macros in the sense that if one macro depends upon
+ another, the latter will be expanded <EM>before</EM> the body of the
+ former. In particular, <SAMP>`AC_REQUIRE(FOO)'</SAMP> is not replaced with the
+ body of <CODE>FOO</CODE>. For instance, this definition of macros:
+
+
+
+ <PRE>
+ AC_DEFUN([TRAVOLTA],
+ [test "$body_temparature_in_celsius" -gt "38" &&
+ dance_floor=occupied])
+ AC_DEFUN([NEWTON_JOHN],
+ [test "$hair_style" = "curly" &&
+ dance_floor=occupied])
+
+ AC_DEFUN([RESERVE_DANCE_FLOOR],
+ [if date | grep '^Sat.*pm' >/dev/null 2>&1; then
+ AC_REQUIRE([TRAVOLTA])
+ AC_REQUIRE([NEWTON_JOHN])
+ fi])
+ </PRE>
+
+ <P>
+ with this <TT>`configure.ac'</TT>
+
+
+
+ <PRE>
+ AC_INIT
+ RESERVE_DANCE_FLOOR
+ if test "$dance_floor" = occupied; then
+ AC_MSG_ERROR([cannot pick up here, let's move])
+ fi
+ </PRE>
+
+ <P>
+ will not leave you with a better chance to meet a kindred soul at
+ other times than Saturday night since it expands into:
+
+
+
+ <PRE>
+ test "$body_temperature_in_Celsius" -gt "38" &&
+ dance_floor=occupied
+ test "$hair_style" = "curly" &&
+ dance_floor=occupied
+ fi
+ if date | grep '^Sat.*pm' >/dev/null 2>&1; then
+
+ fi
+ </PRE>
+
+ <P>
+ This behavior was chosen on purpose: (i) it prevents messages in
+ required macros from interrupting the messages in the requiring macros;
+ (ii) it avoids bad surprises when shell conditionals are used, as in:
+
+
+
+ <PRE>
+ if ...; then
+ AC_REQUIRE([SOME_CHECK])
+ fi
+ ...
+ SOME_CHECK
+ </PRE>
+
+ <P>
+ You are encouraged to put all <CODE>AC_REQUIRE</CODE>s at the beginning of a
+ macro. You can use <CODE>dnl</CODE> to avoid the empty lines they leave.
+
+
+
+
+ <H3><A NAME="SEC107" HREF="autoconf_toc.html#TOC107">Suggested Ordering</A></H3>
+
+ <P>
+ Some macros should be run before another macro if both are called, but
+ neither <EM>requires</EM> that the other be called. For example, a macro
+ that changes the behavior of the C compiler should be called before any
+ macros that run the C compiler. Many of these dependencies are noted in
+ the documentation.
+
+
+ <P>
+ Autoconf provides the <CODE>AC_BEFORE</CODE> macro to warn users when macros
+ with this kind of dependency appear out of order in a
+ <TT>`configure.ac'</TT> file. The warning occurs when creating
+ @command{configure} from <TT>`configure.ac'</TT>, not when running
+ @command{configure}.
+
+
+ <P>
+ For example, <CODE>AC_PROG_CPP</CODE> checks whether the C compiler
+ can run the C preprocessor when given the @option{-E} option. It should
+ therefore be called after any macros that change which C compiler is
+ being used, such as <CODE>AC_PROG_CC</CODE>. So <CODE>AC_PROG_CC</CODE> contains:
+
+
+
+ <PRE>
+ AC_BEFORE([$0], [AC_PROG_CPP])dnl
+ </PRE>
+
+ <P>
+ This warns the user if a call to <CODE>AC_PROG_CPP</CODE> has already occurred
+ when <CODE>AC_PROG_CC</CODE> is called.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_BEFORE</B> <I>(<VAR>this-macro-name</VAR>, <VAR>called-macro-name</VAR>)</I>
+ <DD><A NAME="IDX680"></A>
+ <A NAME="IDX681"></A>
+ Make <CODE>m4</CODE> 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.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC108" HREF="autoconf_toc.html#TOC108">Obsoleting Macros</A></H2>
+
+ <P>
+ Configuration and portability technology has evolved over the years.
+ Often better ways of solving a particular problem are developed, or
+ ad-hoc approaches are systematized. This process has occurred in many
+ parts of Autoconf. One result is that some of the macros are now
+ considered <EM>obsolete</EM>; they still work, but are no longer considered
+ the best thing to do, hence they should be replaced with more modern
+ macros. Ideally, @command{autoupdate} should substitute the old macro calls
+ with their modern implementation.
+
+
+ <P>
+ Autoconf provides a simple means to obsolete a macro.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AU_DEFUN</B> <I>(<VAR>old-macro</VAR>, <VAR>implementation</VAR>, @ovar{message})</I>
+ <DD><A NAME="IDX682"></A>
+ <A NAME="IDX683"></A>
+ <A NAME="IDX684"></A>
+ Define <VAR>old-macro</VAR> as <VAR>implementation</VAR>. The only difference
+ with <CODE>AC_DEFUN</CODE> is that the user will be warned that
+ <VAR>old-macro</VAR> is now obsolete.
+
+
+ <P>
+ If she then uses @command{autoupdate}, the call to <VAR>old-macro</VAR> will be
+ replaced by the modern <VAR>implementation</VAR>. The additional
+ <VAR>message</VAR> is then printed.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC109" HREF="autoconf_toc.html#TOC109">Coding Style</A></H2>
+
+ <P>
+ The Autoconf macros follow a strict coding style. You are encouraged to
+ follow this style, especially if you intend to distribute your macro,
+ either by contributing it to Autoconf itself, or via other means.
+
+
+ <P>
+ The first requirement is to pay great attention to the quotation, for
+ more details, see section <A HREF="autoconf.html#SEC9">The Autoconf Language</A>, and section <A HREF="autoconf.html#SEC88">M4 Quotation</A>.
+
+
+ <P>
+ Do not try to invent new interfaces. It is likely that there is a macro
+ in Autoconf that resembles the macro you are defining: try to stick to
+ this existing interface (order of arguments, default values, etc.). We
+ <EM>are</EM> conscious that some of these interfaces are not perfect;
+ nevertheless, when harmless, homogeneity should be preferred over
+ creativity.
+
+
+ <P>
+ Be careful about clashes both between M4 symbols and between shell
+ variables.
+
+
+ <P>
+ If you stick to the suggested M4 naming scheme (see section <A HREF="autoconf.html#SEC103">Macro Names</A>),
+ you are unlikely to generate conflicts. Nevertheless, when you need to
+ set a special value, <EM>avoid using a regular macro name</EM>; rather,
+ use an "impossible" name. For instance, up to version 2.13, the macro
+ <CODE>AC_SUBST</CODE> used to remember what <VAR>symbol</VAR>s were already defined
+ by setting <CODE>AC_SUBST_<VAR>symbol</VAR></CODE>, which is a regular macro name.
+ But since there is a macro named <CODE>AC_SUBST_FILE</CODE>, it was just
+ impossible to <SAMP>`AC_SUBST(FILE)'</SAMP>! In this case,
+ <CODE>AC_SUBST(<VAR>symbol</VAR>)</CODE> or <CODE>_AC_SUBST(<VAR>symbol</VAR>)</CODE> should
+ have been used (yes, with the parentheses)...or better yet, high-level
+ macros such as <CODE>AC_EXPAND_ONCE</CODE>.
+
+
+ <P>
+ No Autoconf macro should ever enter the user-variable name space; i.e.,
+ except for the variables that are the actual result of running the
+ macro, all shell variables should start with <CODE>ac_</CODE>. In
+ addition, small macros or any macro that is likely to be embedded in
+ other macros should be careful not to use obvious names.
+
+
+ <P>
+ <A NAME="IDX685"></A>
+ Do not use <CODE>dnl</CODE> to introduce comments: most of the comments you
+ are likely to write are either header comments which are not output
+ anyway, or comments that should make their way into <TT>`configure'</TT>.
+ There are exceptional cases where you do want to comment special M4
+ constructs, in which case <CODE>dnl</CODE> is right, but keep in mind that it
+ is unlikely.
+
+
+ <P>
+ M4 ignores the leading spaces before each argument, use this feature to
+ indent in such a way that arguments are (more or less) aligned with the
+ opening parenthesis of the macro being called. For instance, instead of
+
+
+
+ <PRE>
+ AC_CACHE_CHECK(for EMX OS/2 environment,
+ ac_cv_emxos2,
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM(, [return __EMX__;])],
+ [ac_cv_emxos2=yes], [ac_cv_emxos2=no])])
+ </PRE>
+
+ <P>
+ write
+
+
+
+ <PRE>
+ AC_CACHE_CHECK([for EMX OS/2 environment], [ac_cv_emxos2],
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [return __EMX__;])],
+ [ac_cv_emxos2=yes],
+ [ac_cv_emxos2=no])])
+ </PRE>
+
+ <P>
+ or even
+
+
+
+ <PRE>
+ AC_CACHE_CHECK([for EMX OS/2 environment],
+ [ac_cv_emxos2],
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],
+ [return __EMX__;])],
+ [ac_cv_emxos2=yes],
+ [ac_cv_emxos2=no])])
+ </PRE>
+
+ <P>
+ When using <CODE>AC_TRY_RUN</CODE> or any macro that cannot work when
+ cross-compiling, provide a pessimistic value (typically <SAMP>`no'</SAMP>).
+
+
+ <P>
+ Feel free to use various tricks to prevent auxiliary tools, such as
+ syntax-highlighting editors, from behaving improperly. For instance,
+ instead of:
+
+
+
+ <PRE>
+ m4_bpatsubst([$1], [$"])
+ </PRE>
+
+ <P>
+ use
+
+
+
+ <PRE>
+ m4_bpatsubst([$1], [$""])
+ </PRE>
+
+ <P>
+ so that Emacsen do not open a endless "string" at the first quote.
+ For the same reasons, avoid:
+
+
+
+ <PRE>
+ test $[#] != 0
+ </PRE>
+
+ <P>
+ and use:
+
+
+
+ <PRE>
+ test $[@%:@] != 0
+ </PRE>
+
+ <P>
+ Otherwise, the closing bracket would be hidden inside a <SAMP>`#'</SAMP>-comment,
+ breaking the bracket-matching highlighting from Emacsen. Note the
+ preferred style to escape from M4: <SAMP>`$[1]'</SAMP>, <SAMP>`$[@]'</SAMP>, etc. Do
+ not escape when it is unneeded. Common examples of useless quotation
+ are <SAMP>`[$]$1'</SAMP> (write <SAMP>`$$1'</SAMP>), <SAMP>`[$]var'</SAMP> (use <SAMP>`$var'</SAMP>),
+ etc. If you add portability issues to the picture, you'll prefer
+ <SAMP>`${1+"$[@]"}'</SAMP> to <SAMP>`"[$]@"'</SAMP>, and you'll prefer do something
+ better than hacking Autoconf <CODE>:-)</CODE>.
+
+
+ <P>
+ When using @command{sed}, don't use @option{-e} except for indenting
+ purpose. With the <CODE>s</CODE> command, the preferred separator is <SAMP>`/'</SAMP>
+ unless <SAMP>`/'</SAMP> itself is used in the command, in which case you should
+ use <SAMP>`,'</SAMP>.
+
+
+ <P>
+ See section <A HREF="autoconf.html#SEC102">Macro Definitions</A>, for details on how to define a macro. If a
+ macro doesn't use <CODE>AC_REQUIRE</CODE> and it is expected to never be the
+ object of an <CODE>AC_REQUIRE</CODE> directive, then use <CODE>define</CODE>. In
+ case of doubt, use <CODE>AC_DEFUN</CODE>. All the <CODE>AC_REQUIRE</CODE>
+ statements should be at the beginning of the macro, <CODE>dnl</CODE>'ed.
+
+
+ <P>
+ You should not rely on the number of arguments: instead of checking
+ whether an argument is missing, test that it is not empty. It provides
+ both a simpler and a more predictable interface to the user, and saves
+ room for further arguments.
+
+
+ <P>
+ Unless the macro is short, try to leave the closing <SAMP>`])'</SAMP> at the
+ beginning of a line, followed by a comment that repeats the name of the
+ macro being defined. This introduces an additional newline in
+ @command{configure}; normally, that is not a problem, but if you want to
+ remove it you can use <SAMP>`[]dnl'</SAMP> on the last line. You can similarly
+ use <SAMP>`[]dnl'</SAMP> after a macro call to remove its newline. <SAMP>`[]dnl'</SAMP>
+ is recommended instead of <SAMP>`dnl'</SAMP> to ensure that M4 does not
+ interpret the <SAMP>`dnl'</SAMP> as being attached to the preceding text or
+ macro output. For example, instead of:
+
+
+
+ <PRE>
+ AC_DEFUN([AC_PATH_X],
+ [AC_MSG_CHECKING([for X])
+ AC_REQUIRE_CPP()
+ # ...omitted...
+ AC_MSG_RESULT([libraries $x_libraries, headers $x_includes])
+ fi])
+ </PRE>
+
+ <P>
+ you would write:
+
+
+
+ <PRE>
+ AC_DEFUN([AC_PATH_X],
+ [AC_REQUIRE_CPP()[]dnl
+ AC_MSG_CHECKING([for X])
+ # ...omitted...
+ AC_MSG_RESULT([libraries $x_libraries, headers $x_includes])
+ fi[]dnl
+ ])# AC_PATH_X
+ </PRE>
+
+ <P>
+ If the macro is long, try to split it into logical chunks. Typically,
+ macros that check for a bug in a function and prepare its
+ <CODE>AC_LIBOBJ</CODE> replacement should have an auxiliary macro to perform
+ this setup. Do not hesitate to introduce auxiliary macros to factor
+ your code.
+
+
+ <P>
+ In order to highlight the recommended coding style, here is a macro
+ written the old way:
+
+
+
+ <PRE>
+ dnl Check for EMX on OS/2.
+ dnl _AC_EMXOS2
+ AC_DEFUN(_AC_EMXOS2,
+ [AC_CACHE_CHECK(for EMX OS/2 environment, ac_cv_emxos2,
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM(, return __EMX__;)],
+ ac_cv_emxos2=yes, ac_cv_emxos2=no)])
+ test "$ac_cv_emxos2" = yes && EMXOS2=yes])
+ </PRE>
+
+ <P>
+ and the new way:
+
+
+
+ <PRE>
+ # _AC_EMXOS2
+ # ----------
+ # Check for EMX on OS/2.
+ define([_AC_EMXOS2],
+ [AC_CACHE_CHECK([for EMX OS/2 environment], [ac_cv_emxos2],
+ [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [return __EMX__;])],
+ [ac_cv_emxos2=yes],
+ [ac_cv_emxos2=no])])
+ test "$ac_cv_emxos2" = yes && EMXOS2=yes[]dnl
+ ])# _AC_EMXOS2
+ </PRE>
+
+
+
+ <H1><A NAME="SEC110" HREF="autoconf_toc.html#TOC110">Portable Shell Programming</A></H1>
+
+ <P>
+ When writing your own checks, there are some shell-script programming
+ techniques you should avoid in order to make your code portable. The
+ Bourne shell and upward-compatible shells like the Korn shell and Bash
+ have evolved over the years, but to prevent trouble, do not take
+ advantage of features that were added after UNIX version 7, circa
+ 1977. You should not use shell functions, aliases, negated character
+ classes, or other features that are not found in all Bourne-compatible
+ shells; restrict yourself to the lowest common denominator. Even
+ <CODE>unset</CODE> is not supported by all shells! Also, include a space
+ after the exclamation point in interpreter specifications, like this:
+
+
+
+ <PRE>
+ #! /usr/bin/perl
+ </PRE>
+
+ <P>
+ If you omit the space before the path, then 4.2BSD based systems
+ (such as Sequent DYNIX) will ignore the line, because they interpret
+ <SAMP>`#! /'</SAMP> as a 4-byte magic number. Some old systems have quite
+ small limits on the length of the <SAMP>`#!'</SAMP> line too, for instance 32
+ bytes (not including the newline) on SunOS 4.
+
+
+ <P>
+ The set of external programs you should run in a @command{configure} script
+ is fairly small. See section `Utilities in Makefiles' in <CITE>GNU Coding Standards</CITE>, for the list. This
+ restriction allows users to start out with a fairly small set of
+ programs and build the rest, avoiding too many interdependencies between
+ packages.
+
+
+ <P>
+ Some of these external utilities have a portable subset of features; see
+ section <A HREF="autoconf.html#SEC119">Limitations of Usual Tools</A>.
+
+
+
+
+ <H2><A NAME="SEC111" HREF="autoconf_toc.html#TOC111">Shellology</A></H2>
+
+ <P>
+ There are several families of shells, most prominently the Bourne
+ family and the C shell family which are deeply incompatible. If you
+ want to write portable shell scripts, avoid members of the C shell
+ family.
+
+
+ <P>
+ Below we describe some of the members of the Bourne shell family.
+
+
+ <DL COMPACT>
+
+ <DT>Ash
+ <DD>
+ <A NAME="IDX686"></A>
+ @command{ash} is often used on GNU/Linux and BSD systems as a
+ light-weight Bourne-compatible shell. Ash 0.2 has some bugs that are
+ fixed in the 0.3.x series, but portable shell scripts should workaround
+ them, since version 0.2 is still shipped with many GNU/Linux
+ distributions.
+
+ To be compatible with Ash 0.2:
+
+
+ <UL>
+ <LI>
+
+ don't use <SAMP>`$?'</SAMP> after expanding empty or unset variables:
+
+
+ <PRE>
+ foo=
+ false
+ $foo
+ echo "Don't use it: $?"
+ </PRE>
+
+ <LI>
+
+ don't use command substitution within variable expansion:
+
+
+ <PRE>
+ cat ${FOO=`bar`}
+ </PRE>
+
+ <LI>
+
+ beware that single builtin substitutions are not performed by a sub
+ shell, hence their effect applies to the current shell! See section <A HREF="autoconf.html#SEC115">Shell Substitutions</A>, item "Command Substitution".
+ </UL>
+
+ <DT>Bash
+ <DD>
+ <A NAME="IDX687"></A>
+ To detect whether you are running @command{bash}, test if
+ <CODE>BASH_VERSION</CODE> is set. To disable its extensions and require
+ POSIX compatibility, run <SAMP>`set -o posix'</SAMP>. See section `Bash POSIX Mode' in <CITE>The GNU Bash Reference Manual</CITE>, for
+ details.
+
+ <DT>Bash 2.05 and later
+ <DD>
+ <A NAME="IDX688"></A>
+ Versions 2.05 and later of @command{bash} use a different format for the
+ output of the @command{set} builtin, designed to make evaluating this
+ output easier. However, this output is not compatible with earlier
+ versions of @command{bash} (or with many other shells, probably). So if
+ you use @command{bash} 2.05 or higher to execute @command{configure},
+ you'll need to use @command{bash} 2.05 for all other build tasks as well.
+
+ <DT>@command{/usr/xpg4/bin/sh on Solaris}
+ <DD>
+ <A NAME="IDX689"></A>
+ The POSIX-compliant Bourne shell on a Solaris system is
+ @command{/usr/xpg4/bin/sh} and is part of an extra optional package.
+ There is no extra charge for this package, but it is also not part of a
+ minimal OS install and therefore some folks may not have it.
+
+ <DT>Zsh
+ <DD>
+ <A NAME="IDX690"></A>
+ To detect whether you are running @command{zsh}, test if
+ <CODE>ZSH_VERSION</CODE> is set. By default @command{zsh} is <EM>not</EM>
+ compatible with the Bourne shell: you have to run <SAMP>`emulate sh'</SAMP> and
+ set <CODE>NULLCMD</CODE> to <SAMP>`:'</SAMP>. See section `Compatibility' in <CITE>The Z Shell Manual</CITE>, for details.
+
+ Zsh 3.0.8 is the native @command{/bin/sh} on Mac OS X 10.0.3.
+ </DL>
+
+ <P>
+ The following discussion between Russ Allbery and Robert Lipe is worth
+ reading:
+
+
+ <P>
+ Russ Allbery:
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ The GNU assumption that @command{/bin/sh} is the one and only shell
+ leads to a permanent deadlock. Vendors don't want to break user's
+ existant shell scripts, and there are some corner cases in the Bourne
+ shell that are not completely compatible with a POSIX shell. Thus,
+ vendors who have taken this route will <EM>never</EM> (OK..."never say
+ never") replace the Bourne shell (as @command{/bin/sh}) with a
+ POSIX shell.
+ </BLOCKQUOTE>
+
+ <P>
+ Robert Lipe:
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ This is exactly the problem. While most (at least most System V's) do
+ have a Bourne shell that accepts shell functions most vendor
+ @command{/bin/sh} programs are not the POSIX shell.
+
+
+ <P>
+ So while most modern systems do have a shell _somewhere_ that meets the
+ POSIX standard, the challenge is to find it.
+ </BLOCKQUOTE>
+
+
+
+ <H2><A NAME="SEC112" HREF="autoconf_toc.html#TOC112">Here-Documents</A></H2>
+
+ <P>
+ Don't rely on <SAMP>`\'</SAMP> being preserved just because it has no special
+ meaning together with the next symbol. in the native @command{/bin/sh}
+ on OpenBSD 2.7 <SAMP>`\"'</SAMP> expands to <SAMP>`"'</SAMP> in here-documents with
+ unquoted delimiter. As a general rule, if <SAMP>`\\'</SAMP> expands to <SAMP>`\'</SAMP>
+ use <SAMP>`\\'</SAMP> to get <SAMP>`\'</SAMP>.
+
+
+ <P>
+ With OpenBSD 2.7's @command{/bin/sh}
+
+
+
+ <PRE>
+ $ <KBD>cat <<EOF
+ > \" \\
+ > EOF</KBD>
+ " \
+ </PRE>
+
+ <P>
+ and with Bash:
+
+
+
+ <PRE>
+ bash-2.04$ <KBD>cat <<EOF
+ > \" \\
+ > EOF</KBD>
+ \" \
+ </PRE>
+
+ <P>
+ Many older shells (including the Bourne shell) implement here-documents
+ inefficiently. Users can generally speed things up by using a faster
+ shell, e.g., by using the command <SAMP>`bash ./configure'</SAMP> rather than
+ plain <SAMP>`./configure'</SAMP>.
+
+
+ <P>
+ Some shells can be extremely inefficient when there are a lot of
+ here-documents inside a single statement. For instance if your
+ <TT>`configure.ac'</TT> includes something like:
+
+
+
+ <PRE>
+ if <cross_compiling>; then
+ assume this and that
+ else
+ check this
+ check that
+ check something else
+ ...
+ on and on forever
+ ...
+ fi
+ </PRE>
+
+ <P>
+ A shell parses the whole <CODE>if</CODE>/<CODE>fi</CODE> construct, creating
+ temporary files for each here document in it. Some shells create links
+ for such here-documents on every <CODE>fork</CODE>, so that the clean-up code
+ they had installed correctly removes them. It is creating the links
+ that the shell can take forever.
+
+
+ <P>
+ Moving the tests out of the <CODE>if</CODE>/<CODE>fi</CODE>, or creating multiple
+ <CODE>if</CODE>/<CODE>fi</CODE> constructs, would improve the performance
+ significantly. Anyway, this kind of construct is not exactly the
+ typical use of Autoconf. In fact, it's even not recommended, because M4
+ macros can't look into shell conditionals, so we may fail to expand a
+ macro when it was expanded before in a conditional path, and the
+ condition turned out to be false at run-time, and we end up not
+ executing the macro at all.
+
+
+
+
+ <H2><A NAME="SEC113" HREF="autoconf_toc.html#TOC113">File Descriptors</A></H2>
+
+ <P>
+ Some file descriptors shall not be used, since some systems, admittedly
+ arcane, use them for special purpose:
+
+
+
+ <PRE>
+ 3 --- some systems may open it to <SAMP>`/dev/tty'</SAMP>.
+ 4 --- used on the Kubota Titan.
+ </PRE>
+
+ <P>
+ Don't redirect several times the same file descriptor, as you are doomed
+ to failure under Ultrix.
+
+
+
+ <PRE>
+ ULTRIX V4.4 (Rev. 69) System #31: Thu Aug 10 19:42:23 GMT 1995
+ UWS V4.4 (Rev. 11)
+ $ <KBD>eval 'echo matter >fullness' >void</KBD>
+ illegal io
+ $ <KBD>eval '(echo matter >fullness)' >void</KBD>
+ illegal io
+ $ <KBD>(eval '(echo matter >fullness)') >void</KBD>
+ Ambiguous output redirect.
+ </PRE>
+
+ <P>
+ In each case the expected result is of course <TT>`fullness'</TT> containing
+ <SAMP>`matter'</SAMP> and <TT>`void'</TT> being empty.
+
+
+ <P>
+ Don't try to redirect the standard error of a command substitution: it
+ must be done <EM>inside</EM> the command substitution: when running
+ <SAMP>`: `cd /zorglub` 2>/dev/null'</SAMP> expect the error message to
+ escape, while <SAMP>`: `cd /zorglub 2>/dev/null`'</SAMP> works properly.
+
+
+ <P>
+ It is worth noting that Zsh (but not Ash nor Bash) makes it possible
+ in assignments though: <SAMP>`foo=`cd /zorglub` 2>/dev/null'</SAMP>.
+
+
+ <P>
+ Most shells, if not all (including Bash, Zsh, Ash), output traces on
+ stderr, even for sub-shells. This might result in undesired content
+ if you meant to capture the standard-error output of the inner command:
+
+
+
+ <PRE>
+ $ <KBD>ash -x -c '(eval "echo foo >&2") 2>stderr'</KBD>
+ $ <KBD>cat stderr</KBD>
+ + eval echo foo >&2
+ + echo foo
+ foo
+ $ <KBD>bash -x -c '(eval "echo foo >&2") 2>stderr'</KBD>
+ $ <KBD>cat stderr</KBD>
+ + eval 'echo foo >&2'
+ ++ echo foo
+ foo
+ $ <KBD>zsh -x -c '(eval "echo foo >&2") 2>stderr'</KBD>
+ <I># Traces on startup files deleted here.</I>
+ $ <KBD>cat stderr</KBD>
+ +zsh:1> eval echo foo >&2
+ +zsh:1> echo foo
+ foo
+ </PRE>
+
+ <P>
+ You'll appreciate the various levels of detail...
+
+
+ <P>
+ One workaround is to grep out uninteresting lines, hoping not to remove
+ good ones...
+
+
+ <P>
+ Don't try to move/delete open files, such as in <SAMP>`exec >foo; mv foo
+ bar'</SAMP>, see See section <A HREF="autoconf.html#SEC118">Limitations of Shell Builtins</A>, @command{mv} for more details.
+
+
+
+
+ <H2><A NAME="SEC114" HREF="autoconf_toc.html#TOC114">File System Conventions</A></H2>
+
+ <P>
+ While @command{autoconf} and friends will usually be run on some Unix
+ variety, it can and will be used on other systems, most notably DOS
+ variants. This impacts several assumptions regarding file and
+ path names.
+
+
+ <P>
+ For example, the following code:
+
+
+
+ <PRE>
+ case $foo_dir in
+ /*) # Absolute
+ ;;
+ *)
+ foo_dir=$dots$foo_dir ;;
+ esac
+ </PRE>
+
+ <P>
+ will fail to properly detect absolute paths on those systems, because
+ they can use a drivespec, and will usually use a backslash as directory
+ separator. The canonical way to check for absolute paths is:
+
+
+
+ <PRE>
+ case $foo_dir in
+ [\\/]* | ?:[\\/]* ) # Absolute
+ ;;
+ *)
+ foo_dir=$dots$foo_dir ;;
+ esac
+ </PRE>
+
+ <P>
+ Make sure you quote the brackets if appropriate and keep the backslash as
+ first character (see section <A HREF="autoconf.html#SEC118">Limitations of Shell Builtins</A>).
+
+
+ <P>
+ Also, because the colon is used as part of a drivespec, these systems don't
+ use it as path separator. When creating or accessing paths, use the
+ <CODE>PATH_SEPARATOR</CODE> output variable instead. @command{configure} sets this
+ to the appropriate value (<SAMP>`:'</SAMP> or <SAMP>`;'</SAMP>) when it starts up.
+
+
+ <P>
+ File names need extra care as well. While DOS-based environments
+ that are Unixy enough to run @command{autoconf} (such as DJGPP) will
+ usually be able to handle long file names properly, there are still
+ limitations that can seriously break packages. Several of these issues
+ can be easily detected by the
+ @href{ftp://ftp.gnu.org/gnu/non-gnu/doschk/doschk-1.1.tar.gz, doschk}
+ package.
+
+
+ <P>
+ A short overview follows; problems are marked with SFN/LFN to
+ indicate where they apply: SFN means the issues are only relevant to
+ plain DOS, not to DOS boxes under Windows, while LFN
+ identifies problems that exist even under Windows.
+
+
+ <DL COMPACT>
+
+ <DT>No multiple dots (SFN)
+ <DD>
+ DOS cannot handle multiple dots in filenames. This is an especially
+ important thing to remember when building a portable configure script,
+ as @command{autoconf} uses a .in suffix for template files.
+
+ This is perfectly OK on Unices:
+
+
+ <PRE>
+ AC_CONFIG_HEADER(config.h)
+ AC_CONFIG_FILES([source.c foo.bar])
+ AC_OUTPUT
+ </PRE>
+
+ but it causes problems on DOS, as it requires <SAMP>`config.h.in'</SAMP>,
+ <SAMP>`source.c.in'</SAMP> and <SAMP>`foo.bar.in'</SAMP>. To make your package more portable
+ to DOS-based environments, you should use this instead:
+
+
+ <PRE>
+ AC_CONFIG_HEADER(config.h:config.hin)
+ AC_CONFIG_FILES([source.c:source.cin foo.bar:foobar.in])
+ AC_OUTPUT
+ </PRE>
+
+ <DT>No leading dot (SFN)
+ <DD>
+ DOS cannot handle filenames that start with a dot. This is usually
+ not a very important issue for @command{autoconf}.
+
+ <DT>Case insensitivity (LFN)
+ <DD>
+ DOS is case insensitive, so you cannot, for example, have both a
+ file called <SAMP>`INSTALL'</SAMP> and a directory called <SAMP>`install'</SAMP>. This
+ also affects @command{make}; if there's a file called <SAMP>`INSTALL'</SAMP> in
+ the directory, @command{make install} will do nothing (unless the
+ <SAMP>`install'</SAMP> target is marked as PHONY).
+
+ <DT>The 8+3 limit (SFN)
+ <DD>
+ Because the DOS file system only stores the first 8 characters of
+ the filename and the first 3 of the extension, those must be unique.
+ That means that <TT>`foobar-part1.c'</TT>, <TT>`foobar-part2.c'</TT> and
+ <TT>`foobar-prettybird.c'</TT> all resolve to the same filename
+ (<TT>`FOOBAR-P.C'</TT>). The same goes for <TT>`foo.bar'</TT> and
+ <TT>`foo.bartender'</TT>.
+
+ Note: This is not usually a problem under Windows, as it uses numeric
+ tails in the short version of filenames to make them unique. However, a
+ registry setting can turn this behaviour off. While this makes it
+ possible to share file trees containing long file names between SFN
+ and LFN environments, it also means the above problem applies there
+ as well.
+
+ <DT>Invalid characters
+ <DD>
+ Some characters are invalid in DOS filenames, and should therefore
+ be avoided. In a LFN environment, these are <SAMP>`/'</SAMP>, <SAMP>`\'</SAMP>,
+ <SAMP>`?'</SAMP>, <SAMP>`*'</SAMP>, <SAMP>`:'</SAMP>, <SAMP>`<'</SAMP>, <SAMP>`>'</SAMP>, <SAMP>`|'</SAMP> and <SAMP>`"'</SAMP>.
+ In a SFN environment, other characters are also invalid. These
+ include <SAMP>`+'</SAMP>, <SAMP>`,'</SAMP>, <SAMP>`['</SAMP> and <SAMP>`]'</SAMP>.
+ </DL>
+
+
+
+ <H2><A NAME="SEC115" HREF="autoconf_toc.html#TOC115">Shell Substitutions</A></H2>
+
+ <P>
+ Contrary to a persistent urban legend, the Bourne shell does not
+ systematically split variables and backquoted expressions, in particular
+ on the right-hand side of assignments and in the argument of <CODE>case</CODE>.
+ For instance, the following code:
+
+
+
+ <PRE>
+ case "$given_srcdir" in
+ .) top_srcdir="`echo "$dots" | sed 's,/$,,'`"
+ *) top_srcdir="$dots$given_srcdir" ;;
+ esac
+ </PRE>
+
+ <P>
+ is more readable when written as:
+
+
+
+ <PRE>
+ case $given_srcdir in
+ .) top_srcdir=`echo "$dots" | sed 's,/$,,'`
+ *) top_srcdir=$dots$given_srcdir ;;
+ esac
+ </PRE>
+
+ <P>
+ and in fact it is even <EM>more</EM> portable: in the first case of the
+ first attempt, the computation of <CODE>top_srcdir</CODE> is not portable,
+ since not all shells properly understand <CODE>"`..."..."...`"</CODE>.
+ Worse yet, not all shells understand <CODE>"`...\"...\"...`"</CODE>
+ the same way. There is just no portable way to use double-quoted
+ strings inside double-quoted backquoted expressions (pfew!).
+
+
+ <DL COMPACT>
+
+ <DT><CODE>$@</CODE>
+ <DD>
+ <A NAME="IDX691"></A>
+ One of the most famous shell-portability issues is related to
+ <SAMP>`"$@"'</SAMP>: when there are no positional arguments, it is supposed to
+ be equivalent to nothing. But some shells, for instance under Digital
+ Unix 4.0 and 5.0, will then replace it with an empty argument. To be
+ portable, use <SAMP>`${1+"$@"}'</SAMP>.
+
+ <DT><CODE>${<VAR>var</VAR>:-<VAR>value</VAR>}</CODE>
+ <DD>
+ <A NAME="IDX692"></A>
+ Old BSD shells, including the Ultrix <CODE>sh</CODE>, don't accept the
+ colon for any shell substitution, and complain and die.
+
+ <DT><CODE>${<VAR>var</VAR>=<VAR>literal</VAR>}</CODE>
+ <DD>
+ <A NAME="IDX693"></A>
+ Be sure to quote:
+
+
+ <PRE>
+ : ${var='Some words'}
+ </PRE>
+
+ otherwise some shells, such as on Digital Unix V 5.0, will die because
+ of a "bad substitution".
+
+ Solaris' @command{/bin/sh} has a frightening bug in its interpretation
+ of this. Imagine you need set a variable to a string containing
+ <SAMP>`}'</SAMP>. This <SAMP>`}'</SAMP> character confuses Solaris' @command{/bin/sh}
+ when the affected variable was already set. This bug can be exercised
+ by running:
+
+
+ <PRE>
+ $ <KBD>unset foo</KBD>
+ $ <KBD>foo=${foo='}'}</KBD>
+ $ <KBD>echo $foo</KBD>
+ }
+ $ <KBD>foo=${foo='}' # no error; this hints to what the bug is</KBD>
+ $ <KBD>echo $foo</KBD>
+ }
+ $ <KBD>foo=${foo='}'}</KBD>
+ $ <KBD>echo $foo</KBD>
+ }}
+ ^ ugh!
+ </PRE>
+
+ It seems that <SAMP>`}'</SAMP> is interpreted as matching <SAMP>`${'</SAMP>, even
+ though it is enclosed in single quotes. The problem doesn't happen
+ using double quotes.
+
+ <DT><CODE>${<VAR>var</VAR>=<VAR>expanded-value</VAR>}</CODE>
+ <DD>
+ <A NAME="IDX694"></A>
+ On Ultrix,
+ running
+
+
+ <PRE>
+ default="yu,yaa"
+ : ${var="$default"}
+ </PRE>
+
+ will set <VAR>var</VAR> to <SAMP>`M-yM-uM-,M-yM-aM-a'</SAMP>, i.e., the 8th bit of
+ each char will be set. You won't observe the phenomenon using a simple
+ <SAMP>`echo $var'</SAMP> since apparently the shell resets the 8th bit when it
+ expands $var. Here are two means to make this shell confess its sins:
+
+
+ <PRE>
+ $ <KBD>cat -v <<EOF
+ $var
+ EOF</KBD>
+ </PRE>
+
+ and
+
+
+ <PRE>
+ $ <KBD>set | grep '^var=' | cat -v</KBD>
+ </PRE>
+
+ One classic incarnation of this bug is:
+
+
+ <PRE>
+ default="a b c"
+ : ${list="$default"}
+ for c in $list; do
+ echo $c
+ done
+ </PRE>
+
+ You'll get <SAMP>`a b c'</SAMP> on a single line. Why? Because there are no
+ spaces in <SAMP>`$list'</SAMP>: there are <SAMP>`M- '</SAMP>, i.e., spaces with the 8th
+ bit set, hence no IFS splitting is performed!!!
+
+ One piece of good news is that Ultrix works fine with <SAMP>`:
+ ${list=$default}'</SAMP>; i.e., if you <EM>don't</EM> quote. The bad news is
+ then that QNX 4.25 then sets <VAR>list</VAR> to the <EM>last</EM> item of
+ <VAR>default</VAR>!
+
+ The portable way out consists in using a double assignment, to switch
+ the 8th bit twice on Ultrix:
+
+
+ <PRE>
+ list=${list="$default"}
+ </PRE>
+
+ ...but beware of the <SAMP>`}'</SAMP> bug from Solaris (see above). For safety,
+ use:
+
+
+ <PRE>
+ test "${var+set}" = set || var=<VAR>{value}</VAR>
+ </PRE>
+
+ <DT><CODE>`<VAR>commands</VAR>`</CODE>
+ <DD>
+ <A NAME="IDX695"></A>
+ <A NAME="IDX696"></A>
+ While in general it makes no sense, do not substitute a single builtin
+ with side effects as Ash 0.2, trying to optimize, does not fork a
+ sub-shell to perform the command.
+
+ For instance, if you wanted to check that @command{cd} is silent, do not
+ use <SAMP>`test -z "`cd /`"'</SAMP> because the following can happen:
+
+
+ <PRE>
+ $ <KBD>pwd</KBD>
+ /tmp
+ $ <KBD>test -n "`cd /`" && pwd</KBD>
+ /
+ </PRE>
+
+ The result of <SAMP>`foo=`exit 1`'</SAMP> is left as an exercise to the reader.
+
+ <DT><CODE>$(<VAR>commands</VAR>)</CODE>
+ <DD>
+ <A NAME="IDX697"></A>
+ This construct is meant to replace <SAMP>``<VAR>commands</VAR>`'</SAMP>; they can be
+ nested while this is impossible to do portably with back quotes.
+ Unfortunately it is not yet widely supported. Most notably, even recent
+ releases of Solaris don't support it:
+
+
+ <PRE>
+ $ <KBD>showrev -c /bin/sh | grep version</KBD>
+ Command version: SunOS 5.8 Generic 109324-02 February 2001
+ $ <KBD>echo $(echo blah)</KBD>
+ syntax error: `(' unexpected
+ </PRE>
+
+ nor does IRIX 6.5's Bourne shell:
+
+ <PRE>
+ $ <KBD>uname -a</KBD>
+ IRIX firebird-image 6.5 07151432 IP22
+ $ <KBD>echo $(echo blah)</KBD>
+ $(echo blah)
+ </PRE>
+
+ </DL>
+
+
+
+ <H2><A NAME="SEC116" HREF="autoconf_toc.html#TOC116">Assignments</A></H2>
+
+ <P>
+ When setting several variables in a row, be aware that the order of the
+ evaluation is undefined. For instance <SAMP>`foo=1 foo=2; echo $foo'</SAMP>
+ gives <SAMP>`1'</SAMP> with sh on Solaris, but <SAMP>`2'</SAMP> with Bash. You must use
+ <SAMP>`;'</SAMP> to enforce the order: <SAMP>`foo=1; foo=2; echo $foo'</SAMP>.
+
+
+ <P>
+ Don't rely on the exit status of an assignment: Ash 0.2 does not change
+ the status and propagates that of the last statement:
+
+
+
+ <PRE>
+ $ <KBD>false || foo=bar; echo $?</KBD>
+ 1
+ $ <KBD>false || foo=`:`; echo $?</KBD>
+ 0
+ </PRE>
+
+ <P>
+ and to make things even worse, QNX 4.25 just sets the exit status
+ to 0 in any case:
+
+
+
+ <PRE>
+ $ <KBD>foo=`exit 1`; echo $?</KBD>
+ 0
+ </PRE>
+
+ <P>
+ To assign default values, follow this algorithm:
+
+
+
+ <OL>
+ <LI>
+
+ If the default value is a literal and does not contain any closing
+ brace, use:
+
+
+ <PRE>
+ : ${var='my literal'}
+ </PRE>
+
+ <LI>
+
+ If the default value contains no closing brace, has to be expanded, and
+ the variable being initialized will never be IFS-split (i.e., it's not a
+ list), then use:
+
+
+ <PRE>
+ : ${var="$default"}
+ </PRE>
+
+ <LI>
+
+ If the default value contains no closing brace, has to be expanded, and
+ the variable being initialized will be IFS-split (i.e., it's a list),
+ then use:
+
+
+ <PRE>
+ var=${var="$default"}
+ </PRE>
+
+ <LI>
+
+ If the default value contains a closing brace, then use:
+
+
+ <PRE>
+ test "${var+set}" = set || var='${indirection}'
+ </PRE>
+
+ </OL>
+
+ <P>
+ In most cases <SAMP>`var=${var="$default"}'</SAMP> is fine, but in case of
+ doubt, just use the latter. See section <A HREF="autoconf.html#SEC115">Shell Substitutions</A>, items
+ <SAMP>`${<VAR>var</VAR>:-<VAR>value</VAR>}'</SAMP> and <SAMP>`${<VAR>var</VAR>=<VAR>value</VAR>}'</SAMP>
+ for the rationale.
+
+
+
+
+ <H2><A NAME="SEC117" HREF="autoconf_toc.html#TOC117">Special Shell Variables</A></H2>
+
+ <P>
+ Some shell variables should not be used, since they can have a deep
+ influence on the behavior of the shell. In order to recover a sane
+ behavior from the shell, some variables should be unset, but
+ @command{unset} is not portable (see section <A HREF="autoconf.html#SEC118">Limitations of Shell Builtins</A>) and a
+ fallback value is needed. We list these values below.
+
+
+ <DL COMPACT>
+
+ <DT><CODE>CDPATH</CODE>
+ <DD>
+ <A NAME="IDX698"></A>
+ When this variable is set <CODE>cd</CODE> is verbose, so idioms such as
+ <SAMP>`abs=`cd $rel && pwd`'</SAMP> break because <CODE>abs</CODE> receives the path
+ twice.
+
+ Setting <CODE>CDPATH</CODE> to the empty value is not enough for most shells.
+ A simple path separator is enough except for <CODE>zsh</CODE>, which prefers a
+ leading dot:
+
+
+ <PRE>
+ zsh-3.1.6$ <KBD>mkdir foo && (CDPATH=: cd foo)</KBD>
+ /tmp/foo
+ zsh-3.1.6$ <KBD>(CDPATH=:. cd foo)</KBD>
+ /tmp/foo
+ zsh-3.1.6$ <KBD>(CDPATH=.: cd foo)</KBD>
+ zsh-3.1.6$
+ </PRE>
+
+ (of course we could just @command{unset} <CODE>CDPATH</CODE>, since it also
+ behaves properly if set to the empty string).
+
+ Life wouldn't be so much fun if @command{bash} and @command{zsh} had the
+ same behavior:
+
+
+ <PRE>
+ bash-2.02$ <KBD>mkdir foo && (CDPATH=: cd foo)</KBD>
+ bash-2.02$ <KBD>(CDPATH=:. cd foo)</KBD>
+ bash-2.02$ <KBD>(CDPATH=.: cd foo)</KBD>
+ /tmp/foo
+ </PRE>
+
+ Of course, even better style would be to use <CODE>PATH_SEPARATOR</CODE> instead
+ of a <SAMP>`:'</SAMP>.
+ Therefore, a portable solution to neutralize <CODE>CDPATH</CODE> is
+
+
+ <PRE>
+ CDPATH=${ZSH_VERSION+.}$PATH_SEPARATOR
+ </PRE>
+
+ Note that since @command{zsh} supports @command{unset}, you may unset
+ <CODE>CDPATH</CODE> using <CODE>PATH_SEPARATOR</CODE> as a fallback, see
+ section <A HREF="autoconf.html#SEC118">Limitations of Shell Builtins</A>.
+
+ <DT><CODE>IFS</CODE>
+ <DD>
+ <A NAME="IDX699"></A>
+ Don't set the first character of <CODE>IFS</CODE> to backslash. Indeed,
+ Bourne shells use the first character (backslash) when joining the
+ components in <SAMP>`"$@"'</SAMP> and some shells then re-interpret (!) the
+ backslash escapes, so you can end up with backspace and other strange
+ characters.
+
+ <DT><CODE>LANG</CODE>
+ <DD>
+ <DT><CODE>LC_ALL</CODE>
+ <DD>
+ <DT><CODE>LC_COLLATE</CODE>
+ <DD>
+ <DT><CODE>LC_CTYPE</CODE>
+ <DD>
+ <DT><CODE>LC_MESSAGES</CODE>
+ <DD>
+ <DT><CODE>LC_NUMERIC</CODE>
+ <DD>
+ <DT><CODE>LC_TIME</CODE>
+ <DD>
+ <A NAME="IDX700"></A>
+ <A NAME="IDX701"></A>
+ <A NAME="IDX702"></A>
+ <A NAME="IDX703"></A>
+ <A NAME="IDX704"></A>
+ <A NAME="IDX705"></A>
+ <A NAME="IDX706"></A>
+
+ Autoconf-generated scripts normally set all these variables to
+ <SAMP>`C'</SAMP> because so much configuration code assumes the C locale and
+ POSIX requires that @env{LC_ALL} be set to <SAMP>`C'</SAMP> if the C
+ locale is desired. However, some older, nonstandard systems (notably
+ SCO) break if @env{LC_ALL} is set to <SAMP>`C'</SAMP>, so when running on
+ these systems Autoconf-generated scripts first try to unset the
+ variables instead.
+
+ <DT><CODE>LANGUAGE</CODE>
+ <DD>
+ <A NAME="IDX707"></A>
+
+ @env{LANGUAGE} is not specified by POSIX, but it is a GNU
+ extension that overrides @env{LC_ALL} in some cases, so
+ Autoconf-generated scripts set it too.
+
+ <DT><CODE>LINENO</CODE>
+ <DD>
+ <A NAME="IDX708"></A>
+ Most modern shells provide the current line number in <CODE>LINENO</CODE>.
+ Its value is the line number of the beginning of the current command.
+ Autoconf attempts to execute @command{configure} with a modern shell.
+ If no such shell is available, it attempts to implement <CODE>LINENO</CODE>
+ with a Sed prepass that replaces the each instance of the string
+ <CODE>$LINENO</CODE> (not followed by an alphanumeric character) with the
+ line's number.
+
+ You should not rely on <CODE>LINENO</CODE> within @command{eval}, as the
+ behavior differs in practice. Also, the possibility of the Sed
+ prepass means that you should not rely on <CODE>$LINENO</CODE> when quoted,
+ when in here-documents, or when in long commands that cross line
+ boundaries. Subshells should be OK, though. In the following
+ example, lines 1, 6, and 9 are portable, but the other instances of
+ <CODE>LINENO</CODE> are not:
+
+
+ <PRE>
+ $ <KBD>cat lineno</KBD>
+ echo 1. $LINENO
+ cat <<EOF
+ 3. $LINENO
+ 4. $LINENO
+ EOF
+ ( echo 6. $LINENO )
+ eval 'echo 7. $LINENO'
+ echo 8. '$LINENO'
+ echo 9. $LINENO '
+ 10.' $LINENO
+ $ <KBD>bash-2.05 lineno</KBD>
+ 1. 1
+ 3. 2
+ 4. 2
+ 6. 6
+ 7. 1
+ 8. $LINENO
+ 9. 9
+ 10. 9
+ $ <KBD>zsh-3.0.6 lineno</KBD>
+ 1. 1
+ 3. 2
+ 4. 2
+ 6. 6
+ 7. 7
+ 8. $LINENO
+ 9. 9
+ 10. 9
+ $ <KBD>pdksh-5.2.14 lineno</KBD>
+ 1. 1
+ 3. 2
+ 4. 2
+ 6. 6
+ 7. 0
+ 8. $LINENO
+ 9. 9
+ 10. 9
+ $ <KBD>sed '=' <lineno |</KBD>
+ > <KBD> sed '</KBD>
+ > <KBD> N</KBD>
+ > <KBD> s,$,-,</KBD>
+ > <KBD> : loop</KBD>
+ > <KBD> s,^\([0-9]*\)\(.*\)[$]LINENO\([^a-zA-Z0-9_]\),\1\2\1\3,</KBD>
+ > <KBD> t loop</KBD>
+ > <KBD> s,-$,,</KBD>
+ > <KBD> s,^[0-9]*\n,,</KBD>
+ > <KBD> ' |</KBD>
+ > <KBD> sh</KBD>
+ 1. 1
+ 3. 3
+ 4. 4
+ 6. 6
+ 7. 7
+ 8. 8
+ 9. 9
+ 10. 10
+ </PRE>
+
+ <DT><CODE>NULLCMD</CODE>
+ <DD>
+ <A NAME="IDX709"></A>
+ When executing the command <SAMP>`>foo'</SAMP>, @command{zsh} executes
+ <SAMP>`$NULLCMD >foo'</SAMP>. The Bourne shell considers <CODE>NULLCMD</CODE> is
+ <SAMP>`:'</SAMP>, while @command{zsh}, even in Bourne shell compatibility mode,
+ sets <CODE>NULLCMD</CODE> to <SAMP>`cat'</SAMP>. If you forgot to set <CODE>NULLCMD</CODE>,
+ your script might be suspended waiting for data on its standard input.
+
+ <DT><CODE>status</CODE>
+ <DD>
+ <A NAME="IDX710"></A>
+ This variable is an alias to <SAMP>`$?'</SAMP> for <CODE>zsh</CODE> (at least 3.1.6),
+ hence read-only. Do not use it.
+
+ <DT><CODE>PATH_SEPARATOR</CODE>
+ <DD>
+ <A NAME="IDX711"></A>
+ If it is not set, @command{configure} will detect the appropriate path
+ separator for the build system and set the <CODE>PATH_SEPARATOR</CODE> output
+ variable accordingly.
+
+ On DJGPP systems, the <CODE>PATH_SEPARATOR</CODE> environment variable can be
+ set to either <SAMP>`:'</SAMP> or <SAMP>`;'</SAMP> to control the path separator
+ @command{bash} uses to set up certain environment variables (such as
+ <CODE>PATH</CODE>). Since this only works inside @command{bash}, you want
+ @command{configure} to detect the regular DOS path separator
+ (<SAMP>`;'</SAMP>), so it can be safely substituted in files that may not support
+ <SAMP>`;'</SAMP> as path separator. So it is recommended to either unset this
+ variable or set it to <SAMP>`;'</SAMP>.
+
+ <DT><CODE>RANDOM</CODE>
+ <DD>
+ <A NAME="IDX712"></A>
+ Many shells provide <CODE>RANDOM</CODE>, a variable that returns a different
+ integer when used. Most of the time, its value does not change when it
+ is not used, but on IRIX 6.5 the value changes all the time. This
+ can be observed by using @command{set}.
+ </DL>
+
+
+
+ <H2><A NAME="SEC118" HREF="autoconf_toc.html#TOC118">Limitations of Shell Builtins</A></H2>
+
+ <P>
+ No, no, we are serious: some shells do have limitations! :)
+
+
+ <P>
+ You should always keep in mind that any built-in or command may support
+ options, and therefore have a very different behavior with arguments
+ starting with a dash. For instance, the innocent <SAMP>`echo "$word"'</SAMP>
+ can give unexpected results when <CODE>word</CODE> starts with a dash. It is
+ often possible to avoid this problem using <SAMP>`echo "x$word"'</SAMP>, taking
+ the <SAMP>`x'</SAMP> into account later in the pipe.
+
+
+ <DL COMPACT>
+
+ <DT>@command{.}
+ <DD>
+ <A NAME="IDX713"></A>
+ Use @command{.} only with regular files (use <SAMP>`test -f'</SAMP>). Bash
+ 2.03, for instance, chokes on <SAMP>`. /dev/null'</SAMP>. Also, remember that
+ @command{.} uses @env{PATH} if its argument contains no slashes, so if
+ you want to use @command{.} on a file <TT>`foo'</TT> in the current
+ directory, you must use <SAMP>`. ./foo'</SAMP>.
+
+ <DT>@command{!}
+ <DD>
+ <A NAME="IDX714"></A>
+ You can't use @command{!}, you'll have to rewrite your code.
+
+ <DT>@command{break}
+ <DD>
+ <A NAME="IDX715"></A>
+ The use of <SAMP>`break 2'</SAMP>, etcetera, is safe.
+
+ <DT>@command{case}
+ <DD>
+ <A NAME="IDX716"></A>
+ You don't need to quote the argument; no splitting is performed.
+
+ You don't need the final <SAMP>`;;'</SAMP>, but you should use it.
+
+ Because of a bug in its <CODE>fnmatch</CODE>, @command{bash} fails to properly
+ handle backslashes in character classes:
+
+
+ <PRE>
+ bash-2.02$ <KBD>case /tmp in [/\\]*) echo OK;; esac</KBD>
+ bash-2.02$
+ </PRE>
+
+ This is extremely unfortunate, since you are likely to use this code to
+ handle UNIX or MS-DOS absolute paths. To work around this
+ bug, always put the backslash first:
+
+
+ <PRE>
+ bash-2.02$ <KBD>case '\TMP' in [\\/]*) echo OK;; esac</KBD>
+ OK
+ bash-2.02$ <KBD>case /tmp in [\\/]*) echo OK;; esac</KBD>
+ OK
+ </PRE>
+
+ Some shells, such as Ash 0.3.8, are confused by empty
+ <CODE>case</CODE>/<CODE>esac</CODE>:
+
+
+ <PRE>
+ ash-0.3.8 $ <KBD>case foo in esac;</KBD>
+ error-->Syntax error: ";" unexpected (expecting ")")
+ </PRE>
+
+ Many shells still do not support parenthesized cases, which is a pity
+ for those of us using tools that rely on balanced parentheses. For
+ instance, Solaris 2.8's Bourne shell:
+
+
+ <PRE>
+ $ <KBD>case foo in (foo) echo foo;; esac</KBD>
+ error-->syntax error: `(' unexpected
+ </PRE>
+
+ <DT>@command{echo}
+ <DD>
+ <A NAME="IDX717"></A>
+ The simple <CODE>echo</CODE> is probably the most surprising source of
+ portability troubles. It is not possible to use <SAMP>`echo'</SAMP> portably
+ unless both options and escape sequences are omitted. New applications
+ which are not aiming at portability should use <SAMP>`printf'</SAMP> instead of
+ <SAMP>`echo'</SAMP>.
+
+ Don't expect any option. See section <A HREF="autoconf.html#SEC23">Preset Output Variables</A>, <CODE>ECHO_N</CODE>
+ etc. for a means to simulate @option{-c}.
+
+ Do not use backslashes in the arguments, as there is no consensus on
+ their handling. On <SAMP>`echo '\n' | wc -l'</SAMP>, the @command{sh} of
+ Digital Unix 4.0, MIPS RISC/OS 4.52, answer 2, but the Solaris'
+ @command{sh}, Bash and Zsh (in @command{sh} emulation mode) report 1.
+ Please note that the problem is truly @command{echo}: all the shells
+ understand <SAMP>`'\n''</SAMP> as the string composed of a backslash and an
+ <SAMP>`n'</SAMP>.
+
+ Because of these problems, do not pass a string containing arbitrary
+ characters to @command{echo}. For example, <SAMP>`echo "$foo"'</SAMP> is safe
+ if you know that <VAR>foo</VAR>'s value cannot contain backslashes and cannot
+ start with <SAMP>`-'</SAMP>, but otherwise you should use a here-document like
+ this:
+
+
+ <PRE>
+ cat <<EOF
+ $foo
+ EOF
+ </PRE>
+
+ <DT>@command{exit}
+ <DD>
+ <A NAME="IDX718"></A>
+ The default value of @command{exit} is supposed to be <CODE>$?</CODE>;
+ unfortunately, some shells, such as the DJGPP port of Bash 2.04, just
+ perform <SAMP>`exit 0'</SAMP>.
+
+
+ <PRE>
+ bash-2.04$ <KBD>foo=`exit 1` || echo fail</KBD>
+ fail
+ bash-2.04$ <KBD>foo=`(exit 1)` || echo fail</KBD>
+ fail
+ bash-2.04$ <KBD>foo=`(exit 1); exit` || echo fail</KBD>
+ bash-2.04$
+ </PRE>
+
+ Using <SAMP>`exit $?'</SAMP> restores the expected behavior.
+
+ Some shell scripts, such as those generated by @command{autoconf}, use a
+ trap to clean up before exiting. If the last shell command exited with
+ nonzero status, the trap also exits with nonzero status so that the
+ invoker can tell that an error occurred.
+
+ Unfortunately, in some shells, such as Solaris 8 @command{sh}, an exit
+ trap ignores the <CODE>exit</CODE> command's status. In these shells, a trap
+ cannot determine whether it was invoked by plain <CODE>exit</CODE> or by
+ <CODE>exit 1</CODE>. Instead of calling <CODE>exit</CODE> directly, use the
+ <CODE>AC_MSG_ERROR</CODE> macro that has a workaround for this problem.
+
+ <DT>@command{export}
+ <DD>
+ <A NAME="IDX719"></A>
+ The builtin @command{export} dubs <EM>environment variable</EM> a shell
+ variable. Each update of exported variables corresponds to an update of
+ the environment variables. Conversely, each environment variable
+ received by the shell when it is launched should be imported as a shell
+ variable marked as exported.
+
+ Alas, many shells, such as Solaris 2.5, IRIX 6.3, IRIX 5.2, AIX 4.1.5
+ and DU 4.0, forget to @command{export} the environment variables they
+ receive. As a result, two variables are coexisting: the environment
+ variable and the shell variable. The following code demonstrates this
+ failure:
+
+
+ <PRE>
+ #! /bin/sh
+ echo $FOO
+ FOO=bar
+ echo $FOO
+ exec /bin/sh $0
+ </PRE>
+
+ when run with <SAMP>`FOO=foo'</SAMP> in the environment, these shells will print
+ alternately <SAMP>`foo'</SAMP> and <SAMP>`bar'</SAMP>, although it should only print
+ <SAMP>`foo'</SAMP> and then a sequence of <SAMP>`bar'</SAMP>s.
+
+ Therefore you should @command{export} again each environment variable
+ that you update.
+
+ <DT>@command{false}
+ <DD>
+ <A NAME="IDX720"></A>
+ Don't expect @command{false} to exit with status 1: in the native Bourne
+ shell of Solaris 8, it exits with status 255.
+
+ <DT>@command{for}
+ <DD>
+ <A NAME="IDX721"></A>
+ To loop over positional arguments, use:
+
+
+ <PRE>
+ for arg
+ do
+ echo "$arg"
+ done
+ </PRE>
+
+ You may <EM>not</EM> leave the <CODE>do</CODE> on the same line as <CODE>for</CODE>,
+ since some shells improperly grok:
+
+
+ <PRE>
+ for arg; do
+ echo "$arg"
+ done
+ </PRE>
+
+ If you want to explicitly refer to the positional arguments, given the
+ <SAMP>`$@'</SAMP> bug (see section <A HREF="autoconf.html#SEC115">Shell Substitutions</A>), use:
+
+
+ <PRE>
+ for arg in ${1+"$@"}; do
+ echo "$arg"
+ done
+ </PRE>
+
+ <DT>@command{if}
+ <DD>
+ <A NAME="IDX722"></A>
+ Using <SAMP>`!'</SAMP> is not portable. Instead of:
+
+
+ <PRE>
+ if ! cmp -s file file.new; then
+ mv file.new file
+ fi
+ </PRE>
+
+ use:
+
+
+ <PRE>
+ if cmp -s file file.new; then :; else
+ mv file.new file
+ fi
+ </PRE>
+
+ There are shells that do not reset the exit status from an @command{if}:
+
+
+ <PRE>
+ $ <KBD>if (exit 42); then true; fi; echo $?</KBD>
+ 42
+ </PRE>
+
+ whereas a proper shell should have printed <SAMP>`0'</SAMP>. This is especially
+ bad in Makefiles since it produces false failures. This is why properly
+ written Makefiles, such as Automake's, have such hairy constructs:
+
+
+ <PRE>
+ if test -f "$file"; then
+ install "$file" "$dest"
+ else
+ :
+ fi
+ </PRE>
+
+ <DT>@command{set}
+ <DD>
+ <A NAME="IDX723"></A>
+ This builtin faces the usual problem with arguments starting with a
+ dash. Modern shells such as Bash or Zsh understand @option{--} to specify
+ the end of the options (any argument after @option{--} is a parameters,
+ even <SAMP>`-x'</SAMP> for instance), but most shells simply stop the option
+ processing as soon as a non-option argument is found. Therefore, use
+ <SAMP>`dummy'</SAMP> or simply <SAMP>`x'</SAMP> to end the option processing, and use
+ @command{shift} to pop it out:
+
+
+ <PRE>
+ set x $my_list; shift
+ </PRE>
+
+ <DT>@command{shift}
+ <DD>
+ <A NAME="IDX724"></A>
+ Not only is @command{shift}ing a bad idea when there is nothing left to
+ shift, but in addition it is not portable: the shell of MIPS
+ RISC/OS 4.52 refuses to do it.
+
+ <DT>@command{source}
+ <DD>
+ <A NAME="IDX725"></A>
+ This command is not portable, as POSIX does not require it; use
+ @command{.} instead.
+
+ <DT>@command{test}
+ <DD>
+ <A NAME="IDX726"></A>
+ The <CODE>test</CODE> program is the way to perform many file and string
+ tests. It is often invoked by the alternate name <SAMP>`['</SAMP>, but using
+ that name in Autoconf code is asking for trouble since it is an M4 quote
+ character.
+
+ If you need to make multiple checks using <CODE>test</CODE>, combine them with
+ the shell operators <SAMP>`&&'</SAMP> and <SAMP>`||'</SAMP> instead of using the
+ <CODE>test</CODE> operators @option{-a} and @option{-o}. On System V, the
+ precedence of @option{-a} and @option{-o} is wrong relative to the unary
+ operators; consequently, POSIX does not specify them, so using them
+ is nonportable. If you combine <SAMP>`&&'</SAMP> and <SAMP>`||'</SAMP> in the same
+ statement, keep in mind that they have equal precedence.
+
+ You may use <SAMP>`!'</SAMP> with @command{test}, but not with @command{if}:
+ <SAMP>`test ! -r foo || exit 1'</SAMP>.
+
+ <DT>@command{test (files)}
+ <DD>
+ To enable @command{configure} scripts to support cross-compilation, they
+ shouldn't do anything that tests features of the build system instead of
+ the host system. But occasionally you may find it necessary to check
+ whether some arbitrary file exists. To do so, use <SAMP>`test -f'</SAMP> or
+ <SAMP>`test -r'</SAMP>. Do not use <SAMP>`test -x'</SAMP>, because 4.3BSD does not
+ have it. Do not use <SAMP>`test -e'</SAMP> either, because Solaris 2.5 does not
+ have it.
+
+ <DT>@command{test (strings)}
+ <DD>
+ Avoid <SAMP>`test "<VAR>string</VAR>"'</SAMP>, in particular if <VAR>string</VAR> might
+ start with a dash, since <CODE>test</CODE> might interpret its argument as an
+ option (e.g., <SAMP>`<VAR>string</VAR> = "-n"'</SAMP>).
+
+ Contrary to a common belief, <SAMP>`test -n <VAR>string</VAR>'</SAMP> and <SAMP>`test
+ -z <VAR>string</VAR>'</SAMP> <STRONG>are</STRONG> portable, nevertheless many shells (such
+ as Solaris 2.5, AIX 3.2, UNICOS 10.0.0.6, Digital Unix 4 etc.) have
+ bizarre precedence and may be confused if <VAR>string</VAR> looks like an
+ operator:
+
+
+ <PRE>
+ $ <KBD>test -n =</KBD>
+ test: argument expected
+ </PRE>
+
+ If there are risks, use <SAMP>`test "x<VAR>string</VAR>" = x'</SAMP> or <SAMP>`test
+ "x<VAR>string</VAR>" != x'</SAMP> instead.
+
+ It is frequent to find variations of the following idiom:
+
+
+ <PRE>
+ test -n "`echo $ac_feature | sed 's/[-a-zA-Z0-9_]//g'`" &&
+ <VAR>action</VAR>
+ </PRE>
+
+ to take an action when a token matches a given pattern. Such constructs
+ should always be avoided by using:
+
+
+ <PRE>
+ echo "$ac_feature" | grep '[^-a-zA-Z0-9_]' >/dev/null 2>&1 &&
+ <VAR>action</VAR>
+ </PRE>
+
+ Use <CODE>case</CODE> where possible since it is faster, being a shell builtin:
+
+
+ <PRE>
+ case $ac_feature in
+ *[!-a-zA-Z0-9_]*) <VAR>action</VAR>;;
+ esac
+ </PRE>
+
+ Alas, negated character classes are probably not portable, although no
+ shell is known to not support the POSIX.2 syntax <SAMP>`[!...]'</SAMP>
+ (when in interactive mode, @command{zsh} is confused by the
+ <SAMP>`[!...]'</SAMP> syntax and looks for an event in its history because of
+ <SAMP>`!'</SAMP>). Many shells do not support the alternative syntax
+ <SAMP>`[^...]'</SAMP> (Solaris, Digital Unix, etc.).
+
+ One solution can be:
+
+
+ <PRE>
+ expr "$ac_feature" : '.*[^-a-zA-Z0-9_]' >/dev/null &&
+ <VAR>action</VAR>
+ </PRE>
+
+ or better yet
+
+
+ <PRE>
+ expr "x$ac_feature" : '.*[^-a-zA-Z0-9_]' >/dev/null &&
+ <VAR>action</VAR>
+ </PRE>
+
+ <SAMP>`expr "X<VAR>foo</VAR>" : "X<VAR>bar</VAR>"'</SAMP> is more robust than <SAMP>`echo
+ "X<VAR>foo</VAR>" | grep "^X<VAR>bar</VAR>"'</SAMP>, because it avoids problems when
+ <SAMP>`<VAR>foo</VAR>'</SAMP> contains backslashes.
+
+ <DT>@command{trap}
+ <DD>
+ <A NAME="IDX727"></A>
+ It is safe to trap at least the signals 1, 2, 13 and 15. You can also
+ trap 0, i.e., have the @command{trap} run when the script ends (either via an
+ explicit @command{exit}, or the end of the script).
+
+ Although POSIX is not absolutely clear on this point, it is widely
+ admitted that when entering the trap <SAMP>`$?'</SAMP> should be set to the exit
+ status of the last command run before the trap. The ambiguity can be
+ summarized as: "when the trap is launched by an @command{exit}, what is
+ the <EM>last</EM> command run: that before @command{exit}, or
+ @command{exit} itself?"
+
+ Bash considers @command{exit} to be the last command, while Zsh and
+ Solaris 8 @command{sh} consider that when the trap is run it is
+ <EM>still</EM> in the @command{exit}, hence it is the previous exit status
+ that the trap receives:
+
+
+ <PRE>
+ $ <KBD>cat trap.sh</KBD>
+ trap 'echo $?' 0
+ (exit 42); exit 0
+ $ <KBD>zsh trap.sh</KBD>
+ 42
+ $ <KBD>bash trap.sh</KBD>
+ 0
+ </PRE>
+
+ The portable solution is then simple: when you want to <SAMP>`exit 42'</SAMP>,
+ run <SAMP>`(exit 42); exit 42'</SAMP>, the first @command{exit} being used to
+ set the exit status to 42 for Zsh, and the second to trigger the trap
+ and pass 42 as exit status for Bash.
+
+ The shell in FreeBSD 4.0 has the following bug: <SAMP>`$?'</SAMP> is reset to 0
+ by empty lines if the code is inside @command{trap}.
+
+
+ <PRE>
+ $ <KBD>trap 'false</KBD>
+
+ echo $?' 0
+ $ <KBD>exit</KBD>
+ 0
+ </PRE>
+
+ Fortunately, this bug only affects @command{trap}.
+
+ <DT>@command{true}
+ <DD>
+ <A NAME="IDX728"></A>
+ <A NAME="IDX729"></A>
+ Don't worry: as far as we know @command{true} is portable.
+ Nevertheless, it's not always a builtin (e.g., Bash 1.x), and the
+ portable shell community tends to prefer using @command{:}. This has a
+ funny side effect: when asked whether @command{false} is more portable
+ than @command{true} Alexandre Oliva answered:
+
+
+ <BLOCKQUOTE>
+ <P>
+ In a sense, yes, because if it doesn't exist, the shell will produce an
+ exit status of failure, which is correct for @command{false}, but not
+ for @command{true}.
+ </BLOCKQUOTE>
+
+ <DT>@command{unset}
+ <DD>
+ <A NAME="IDX730"></A>
+ You cannot assume the support of @command{unset}, nevertheless, because
+ it is extremely useful to disable embarrassing variables such as
+ <CODE>CDPATH</CODE>, you can test for its existence and use
+ it <EM>provided</EM> you give a neutralizing value when @command{unset} is
+ not supported:
+
+
+ <PRE>
+ if (unset FOO) >/dev/null 2>&1; then
+ unset=unset
+ else
+ unset=false
+ fi
+ $unset CDPATH || CDPATH=:
+ </PRE>
+
+ See section <A HREF="autoconf.html#SEC117">Special Shell Variables</A>, for some neutralizing values. Also, see
+ section <A HREF="autoconf.html#SEC118">Limitations of Shell Builtins</A>, documentation of @command{export}, for
+ the case of environment variables.
+ </DL>
+
+
+
+ <H2><A NAME="SEC119" HREF="autoconf_toc.html#TOC119">Limitations of Usual Tools</A></H2>
+
+ <P>
+ The small set of tools you can expect to find on any machine can still
+ include some limitations you should be aware of.
+
+
+ <DL COMPACT>
+
+ <DT>@command{awk}
+ <DD>
+ <A NAME="IDX731"></A>
+ Don't leave white spaces before the parentheses in user functions calls,
+ GNU awk will reject it:
+
+
+ <PRE>
+ $ <KBD>gawk 'function die () { print "Aaaaarg!" }
+ BEGIN { die () }'</KBD>
+ gawk: cmd. line:2: BEGIN { die () }
+ gawk: cmd. line:2: ^ parse error
+ $ <KBD>gawk 'function die () { print "Aaaaarg!" }
+ BEGIN { die() }'</KBD>
+ Aaaaarg!
+ </PRE>
+
+ If you want your program to be deterministic, don't depend on <CODE>for</CODE>
+ on arrays:
+
+
+ <PRE>
+ $ <KBD>cat for.awk</KBD>
+ END {
+ arr["foo"] = 1
+ arr["bar"] = 1
+ for (i in arr)
+ print i
+ }
+ $ <KBD>gawk -f for.awk </dev/null</KBD>
+ foo
+ bar
+ $ <KBD>nawk -f for.awk </dev/null</KBD>
+ bar
+ foo
+ </PRE>
+
+ Some AWK, such as HPUX 11.0's native one, have regex engines fragile to
+ inner anchors:
+
+
+ <PRE>
+ $ <KBD>echo xfoo | $AWK '/foo|^bar/ { print }'</KBD>
+ $ <KBD>echo bar | $AWK '/foo|^bar/ { print }'</KBD>
+ bar
+ $ <KBD>echo xfoo | $AWK '/^bar|foo/ { print }'</KBD>
+ xfoo
+ $ <KBD>echo bar | $AWK '/^bar|foo/ { print }'</KBD>
+ bar
+ </PRE>
+
+ Either do not depend on such patterns (i.e., use <SAMP>`/^(.*foo|bar)/'</SAMP>,
+ or use a simple test to reject such AWK.
+
+ <DT>@command{cat}
+ <DD>
+ <A NAME="IDX732"></A>
+ Don't rely on any option. The option @option{-v}, which displays
+ non-printing characters, <EM>seems</EM> portable, though.
+
+ <DT>@command{cc}
+ <DD>
+ When a compilation such as <SAMP>`cc foo.c -o foo'</SAMP> fails, some compilers
+ (such as CDS on Reliant UNIX) leave a <TT>`foo.o'</TT>.
+
+ HP-UX @command{cc} doesn't accept <TT>`.S'</TT> files to preprocess and
+ assemble. <SAMP>`cc -c foo.S'</SAMP> will appear to succeed, but in fact does
+ nothing.
+
+ <DT>@command{cmp}
+ <DD>
+ <A NAME="IDX733"></A>
+ @command{cmp} performs a raw data comparison of two files, while
+ @command{diff} compares two text files. Therefore, if you might compare
+ DOS files, even if only checking whether two files are different, use
+ @command{diff} to avoid spurious differences due to differences of
+ newline encoding.
+
+ <DT>@command{cp}
+ <DD>
+ <A NAME="IDX734"></A>
+ SunOS @command{cp} does not support @option{-f}, although its
+ @command{mv} does. It's possible to deduce why @command{mv} and
+ @command{cp} are different with respect to @option{-f}. @command{mv}
+ prompts by default before overwriting a read-only file. @command{cp}
+ does not. Therefore, @command{mv} requires a @option{-f} option, but
+ @command{cp} does not. @command{mv} and @command{cp} behave differently
+ with respect to read-only files because the simplest form of
+ @command{cp} cannot overwrite a read-only file, but the simplest form of
+ @command{mv} can. This is because @command{cp} opens the target for
+ write access, whereas @command{mv} simply calls <CODE>link</CODE> (or, in
+ newer systems, <CODE>rename</CODE>).
+
+ <DT>@command{date}
+ <DD>
+ <A NAME="IDX735"></A>
+ Some versions of @command{date} do not recognize special % directives,
+ and unfortunately, instead of complaining, they just pass them through,
+ and exit with success:
+
+
+ <PRE>
+ $ <KBD>uname -a</KBD>
+ OSF1 medusa.sis.pasteur.fr V5.1 732 alpha
+ $ <KBD>date "+%s"</KBD>
+ %s
+ </PRE>
+
+ <DT>@command{diff}
+ <DD>
+ <A NAME="IDX736"></A>
+ Option @option{-u} is nonportable.
+
+ Some implementations, such as Tru64's, fail when comparing to
+ <TT>`/dev/null'</TT>. Use an empty file instead.
+
+ <DT>@command{dirname}
+ <DD>
+ <A NAME="IDX737"></A>
+ Not all hosts have a working @command{dirname}, and you should instead
+ use <CODE>AS_DIRNAME</CODE> (see section <A HREF="autoconf.html#SEC100">Programming in M4sh</A>). For example:
+
+
+ <PRE>
+ dir=`dirname "$file"` # This is not portable.
+ dir=`AS_DIRNAME(["$file"])` # This is more portable.
+ </PRE>
+
+ This handles a few subtleties in the standard way required by
+ POSIX. For example, under UN*X, should <SAMP>`dirname //1'</SAMP> give
+ <SAMP>`/'</SAMP>? Paul Eggert answers:
+
+
+ <BLOCKQUOTE>
+ <P>
+ No, under some older flavors of Unix, leading <SAMP>`//'</SAMP> is a special
+ path name: it refers to a "super-root" and is used to access other
+ machines' files. Leading <SAMP>`///'</SAMP>, <SAMP>`////'</SAMP>, etc. are equivalent
+ to <SAMP>`/'</SAMP>; but leading <SAMP>`//'</SAMP> is special. I think this tradition
+ started with Apollo Domain/OS, an OS that is still in use on some older
+ hosts.
+
+
+ <P>
+ POSIX allows but does not require the special treatment for <SAMP>`//'</SAMP>.
+ It says that the behavior of dirname on path names of the form
+ <SAMP>`//([^/]+/*)?'</SAMP> is implementation defined. In these cases, GNU
+ @command{dirname} returns <SAMP>`/'</SAMP>, but it's more portable to return
+ <SAMP>`//'</SAMP> as this works even on those older flavors of Unix.
+ </BLOCKQUOTE>
+
+ <DT>@command{egrep}
+ <DD>
+ <A NAME="IDX738"></A>
+ The empty alternative is not portable, use <SAMP>`?'</SAMP> instead. For
+ instance with Digital Unix v5.0:
+
+
+ <PRE>
+ > printf "foo\n|foo\n" | egrep '^(|foo|bar)$'
+ |foo
+ > printf "bar\nbar|\n" | egrep '^(foo|bar|)$'
+ bar|
+ > printf "foo\nfoo|\n|bar\nbar\n" | egrep '^(foo||bar)$'
+ foo
+ |bar
+ </PRE>
+
+ @command{egrep} also suffers the limitations of @command{grep}.
+
+ <DT>@command{expr}
+ <DD>
+ <A NAME="IDX739"></A>
+ No @command{expr} keyword starts with <SAMP>`x'</SAMP>, so use @samp{expr
+ x"<VAR>word</VAR>" : 'x<VAR>regex</VAR>'} to keep @command{expr} from
+ misinterpreting <VAR>word</VAR>.
+
+ Don't use <CODE>length</CODE>, <CODE>substr</CODE>, <CODE>match</CODE> and <CODE>index</CODE>.
+
+ <DT>@command{expr (<SAMP>`|'</SAMP>)}
+ <DD>
+ <A NAME="IDX740"></A>
+ You can use <SAMP>`|'</SAMP>. Although POSIX does require that <SAMP>`expr
+ "'</SAMP> return the empty string, it does not specify the result when you
+ <SAMP>`|'</SAMP> together the empty string (or zero) with the empty string. For
+ example:
+
+
+ <PRE>
+ expr '' \| ''
+ </PRE>
+
+ GNU/Linux and POSIX.2-1992 return the empty string for this
+ case, but traditional Unix returns <SAMP>`0'</SAMP> (Solaris is one such
+ example). In the latest POSIX draft, the specification has been
+ changed to match traditional Unix's behavior (which is bizarre, but it's
+ too late to fix this). Please note that the same problem does arise
+ when the empty string results from a computation, as in:
+
+
+ <PRE>
+ expr bar : foo \| foo : bar
+ </PRE>
+
+ Avoid this portability problem by avoiding the empty string.
+
+ <DT>@command{expr (<SAMP>`:'</SAMP>)}
+ <DD>
+ <A NAME="IDX741"></A>
+ Don't use <SAMP>`\?'</SAMP>, <SAMP>`\+'</SAMP> and <SAMP>`\|'</SAMP> in patterns, they are
+ not supported on Solaris.
+
+ The POSIX.2-1992 standard is ambiguous as to whether <SAMP>`expr a :
+ b'</SAMP> (and <SAMP>`expr 'a' : '\(b\)''</SAMP>) output <SAMP>`0'</SAMP> or the empty string.
+ In practice, it outputs the empty string on most platforms, but portable
+ scripts should not assume this. For instance, the QNX 4.25 native
+ @command{expr} returns <SAMP>`0'</SAMP>.
+
+ You may believe that one means to get a uniform behavior would be to use
+ the empty string as a default value:
+
+
+ <PRE>
+ expr a : b \| ''
+ </PRE>
+
+ unfortunately this behaves exactly as the original expression, see the
+ <SAMP>`@command{expr'</SAMP> (<SAMP>`:'</SAMP>)} entry for more information.
+
+ Older @command{expr} implementations (e.g. SunOS 4 @command{expr} and
+ Solaris 8 @command{/usr/ucb/expr}) have a silly length limit that causes
+ @command{expr} to fail if the matched substring is longer than 120
+ bytes. In this case, you might want to fall back on <SAMP>`echo|sed'</SAMP> if
+ @command{expr} fails.
+
+ Don't leave, there is some more!
+
+ The QNX 4.25 @command{expr}, in addition of preferring <SAMP>`0'</SAMP> to
+ the empty string, has a funny behavior in its exit status: it's always 1
+ when parentheses are used!
+
+
+ <PRE>
+ $ <KBD>val=`expr 'a' : 'a'`; echo "$?: $val"</KBD>
+ 0: 1
+ $ <KBD>val=`expr 'a' : 'b'`; echo "$?: $val"</KBD>
+ 1: 0
+
+ $ <KBD>val=`expr 'a' : '\(a\)'`; echo "?: $val"</KBD>
+ 1: a
+ $ <KBD>val=`expr 'a' : '\(b\)'`; echo "?: $val"</KBD>
+ 1: 0
+ </PRE>
+
+ In practice this can be a big problem if you are ready to catch failures
+ of @command{expr} programs with some other method (such as using
+ @command{sed}), since you may get twice the result. For instance
+
+
+ <PRE>
+ $ <KBD>expr 'a' : '\(a\)' || echo 'a' | sed 's/^\(a\)$/\1/'</KBD>
+ </PRE>
+
+ will output <SAMP>`a'</SAMP> on most hosts, but <SAMP>`aa'</SAMP> on QNX 4.25. A
+ simple work around consists in testing @command{expr} and use a variable
+ set to @command{expr} or to @command{false} according to the result.
+
+ <DT>@command{find}
+ <DD>
+ The option @option{-maxdepth} seems to be GNU specific. Tru64 v5.1,
+ NetBSD 1.5 and Solaris 2.5 @command{find} commands do not understand it.
+
+ The replacement of <SAMP>`{}'</SAMP> is guaranteed only if the argument is
+ exactly <EM>{}</EM>, not if it's only a part of an argument. For
+ instance on DU, and HP-UX 10.20 and HP-UX 11:
+
+
+ <PRE>
+ $ <KBD>touch foo</KBD>
+ $ <KBD>find . -name foo -exec echo "{}-{}" \;</KBD>
+ {}-{}
+ </PRE>
+
+ while GNU @command{find} reports <SAMP>`./foo-./foo'</SAMP>.
+
+ <DT>@command{grep}
+ <DD>
+ <A NAME="IDX742"></A>
+ Don't use <SAMP>`grep -s'</SAMP> to suppress output, because <SAMP>`grep -s'</SAMP> on
+ System V does not suppress output, only error messages. Instead,
+ redirect the standard output and standard error (in case the file
+ doesn't exist) of <CODE>grep</CODE> to <TT>`/dev/null'</TT>. Check the exit
+ status of <CODE>grep</CODE> to determine whether it found a match.
+
+ Don't use multiple regexps with @option{-e}, as some <CODE>grep</CODE> will only
+ honor the last pattern (eg., IRIX 6.5 and Solaris 2.5.1). Anyway,
+ Stardent Vistra SVR4 <CODE>grep</CODE> lacks @option{-e}... Instead, use
+ alternation and <CODE>egrep</CODE>.
+
+ <DT>@command{ln}
+ <DD>
+ <A NAME="IDX743"></A>
+ <A NAME="IDX744"></A>
+ Don't rely on @command{ln} having a @option{-f} option. Symbolic links
+ are not available on old systems, use <SAMP>`ln'</SAMP> as a fall back.
+
+ For versions of the DJGPP before 2.04, @command{ln} emulates soft links
+ for executables by generating a stub that in turn calls the real
+ program. This feature also works with nonexistent files like in the
+ Unix spec. So <SAMP>`ln -s file link'</SAMP> will generate <TT>`link.exe'</TT>,
+ which will attempt to call <TT>`file.exe'</TT> if run. But this feature only
+ works for executables, so <SAMP>`cp -p'</SAMP> is used instead for these
+ systems. DJGPP versions 2.04 and later have full symlink support.
+
+ <DT>@command{mv}
+ <DD>
+ <A NAME="IDX745"></A>
+ <A NAME="IDX746"></A>
+ The only portable options are @option{-f} and @option{-i}.
+
+ Moving individual files between file systems is portable (it was in V6),
+ but it is not always atomic: when doing <SAMP>`mv new existing'</SAMP>, there's
+ a critical section where neither the old nor the new version of
+ <TT>`existing'</TT> actually exists.
+
+ Moving directories across mount points is not portable, use @command{cp}
+ and @command{rm}.
+
+ Moving/Deleting open files isn't portable. The following can't be done
+ on DOS/WIN32:
+
+
+ <PRE>
+ exec > foo
+ mv foo bar
+ </PRE>
+
+ nor can
+
+
+ <PRE>
+ exec > foo
+ rm -f foo
+ </PRE>
+
+ <DT>@command{sed}
+ <DD>
+ <A NAME="IDX747"></A>
+ Patterns should not include the separator (unless escaped), even as part
+ of a character class. In conformance with POSIX, the Cray
+ @command{sed} will reject <SAMP>`s/[^/]*$//'</SAMP>: use <SAMP>`s,[^/]*$,,'</SAMP>.
+
+ Sed scripts should not use branch labels longer than 8 characters and
+ should not contain comments.
+
+ Don't include extra <SAMP>`;'</SAMP>, as some @command{sed}, such as NetBSD
+ 1.4.2's, try to interpret the second as a command:
+
+
+ <PRE>
+ $ <KBD>echo a | sed 's/x/x/;;s/x/x/'</KBD>
+ sed: 1: "s/x/x/;;s/x/x/": invalid command code ;
+ </PRE>
+
+ Input should have reasonably long lines, since some @command{sed} have
+ an input buffer limited to 4000 bytes.
+
+ Alternation, <SAMP>`\|'</SAMP>, is common but POSIX.2 does not require its
+ support, so it should be avoided in portable scripts. Solaris 8
+ @command{sed} does not support alternation; e.g. <SAMP>`sed '/a\|b/d''</SAMP>
+ deletes only lines that contain the literal string <SAMP>`a|b'</SAMP>.
+
+ Anchors (<SAMP>`^'</SAMP> and <SAMP>`$'</SAMP>) inside groups are not portable.
+
+ Nested parenthesization in patterns (e.g., <SAMP>`\(\(a*\)b*)\)'</SAMP>) is
+ quite portable to modern hosts, but is not supported by some older
+ @command{sed} implementations like SVR3.
+
+ Of course the option @option{-e} is portable, but it is not needed. No
+ valid Sed program can start with a dash, so it does not help
+ disambiguating. Its sole usefulness is helping enforcing indenting as
+ in:
+
+
+ <PRE>
+ sed -e <VAR>instruction-1</VAR> \
+ -e <VAR>instruction-2</VAR>
+ </PRE>
+
+ as opposed to
+
+
+ <PRE>
+ sed <VAR>instruction-1</VAR>;<VAR>instruction-2</VAR>
+ </PRE>
+
+ Contrary to yet another urban legend, you may portably use <SAMP>`&'</SAMP> in
+ the replacement part of the <CODE>s</CODE> command to mean "what was
+ matched". All descendents of Bell Lab's V7 @command{sed} (at least; we
+ don't have first hand experience with older @command{sed}s) have
+ supported it.
+
+ <DT>@command{sed (<SAMP>`t'</SAMP>)}
+ <DD>
+ <A NAME="IDX748"></A>
+ Some old systems have @command{sed} that "forget" to reset their
+ <SAMP>`t'</SAMP> flag when starting a new cycle. For instance on MIPS
+ RISC/OS, and on IRIX 5.3, if you run the following @command{sed}
+ script (the line numbers are not actual part of the texts):
+
+
+ <PRE>
+ s/keep me/kept/g # a
+ t end # b
+ s/.*/deleted/g # c
+ : end # d
+ </PRE>
+
+ on
+
+
+ <PRE>
+ delete me # 1
+ delete me # 2
+ keep me # 3
+ delete me # 4
+ </PRE>
+
+ you get
+
+
+ <PRE>
+ deleted
+ delete me
+ kept
+ deleted
+ </PRE>
+
+ instead of
+
+
+ <PRE>
+ deleted
+ deleted
+ kept
+ deleted
+ </PRE>
+
+ Why? When processing 1, a matches, therefore sets the t flag, b jumps to
+ d, and the output is produced. When processing line 2, the t flag is
+ still set (this is the bug). Line a fails to match, but @command{sed}
+ is not supposed to clear the t flag when a substitution fails. Line b
+ sees that the flag is set, therefore it clears it, and jumps to d, hence
+ you get <SAMP>`delete me'</SAMP> instead of <SAMP>`deleted'</SAMP>. When processing 3 t
+ is clear, a matches, so the flag is set, hence b clears the flags and
+ jumps. Finally, since the flag is clear, 4 is processed properly.
+
+ There are two things one should remind about <SAMP>`t'</SAMP> in @command{sed}.
+ Firstly, always remember that <SAMP>`t'</SAMP> jumps if <EM>some</EM> substitution
+ succeeded, not only the immediately preceding substitution, therefore,
+ always use a fake <SAMP>`t clear; : clear'</SAMP> to reset the t flag where
+ indeed.
+
+ Secondly, you cannot rely on @command{sed} to clear the flag at each new
+ cycle.
+
+ One portable implementation of the script above is:
+
+
+ <PRE>
+ t clear
+ : clear
+ s/keep me/kept/g
+ t end
+ s/.*/deleted/g
+ : end
+ </PRE>
+
+ <DT>@command{touch}
+ <DD>
+ <A NAME="IDX749"></A>
+ On some old BSD systems, @command{touch} or any command that
+ results in an empty file does not update the timestamps, so use a
+ command like <CODE>echo</CODE> as a workaround.
+
+ GNU @command{touch} 3.16r (and presumably all before that) fails to work
+ on SunOS 4.1.3 when the empty file is on an NFS-mounted 4.2 volume.
+
+ </DL>
+
+
+
+ <H2><A NAME="SEC120" HREF="autoconf_toc.html#TOC120">Limitations of Make</A></H2>
+
+ <P>
+ Make itself suffers a great number of limitations, only a few of which
+ being listed here. First of all, remember that since commands are
+ executed by the shell, all its weaknesses are inherited...
+
+
+ <DL COMPACT>
+
+ <DT><CODE>$<</CODE>
+ <DD>
+ POSIX says that the <SAMP>`$<'</SAMP> construct in makefiles can be used
+ only in inference rules and in the <SAMP>`.DEFAULT'</SAMP> rule; its meaning in
+ ordinary rules is unspecified. Solaris 8's @command{make} for instance
+ will replace it with the argument.
+
+ <DT>Leading underscore in macro names
+ <DD>
+ Some Make don't support leading underscores in macro names, such as on
+ NEWS-OS 4.2R.
+
+
+ <PRE>
+ $ <KBD>cat Makefile</KBD>
+ _am_include = #
+ _am_quote =
+ all:; @echo this is test
+ $ <KBD>make</KBD>
+ Make: Must be a separator on rules line 2. Stop.
+ $ <KBD>cat Makefile2</KBD>
+ am_include = #
+ am_quote =
+ all:; @echo this is test
+ $ <KBD>make -f Makefile2</KBD>
+ this is test
+ </PRE>
+
+ <DT><CODE>VPATH</CODE>
+ <DD>
+ <A NAME="IDX750"></A>
+ Don't use it! For instance any assignment to <CODE>VPATH</CODE> causes Sun
+ @command{make} to only execute the first set of double-colon rules.
+ </DL>
+
+
+
+ <H1><A NAME="SEC121" HREF="autoconf_toc.html#TOC121">Manual Configuration</A></H1>
+
+ <P>
+ A few kinds of features can't be guessed automatically by running test
+ programs. For example, the details of the object-file format, or
+ special options that need to be passed to the compiler or linker. You
+ can check for such features using ad-hoc means, such as having
+ @command{configure} check the output of the <CODE>uname</CODE> program, or
+ looking for libraries that are unique to particular systems. However,
+ Autoconf provides a uniform method for handling unguessable features.
+
+
+
+
+ <H2><A NAME="SEC122" HREF="autoconf_toc.html#TOC122">Specifying the System Type</A></H2>
+
+ <P>
+ Like other GNU @command{configure} scripts, Autoconf-generated
+ @command{configure} scripts can make decisions based on a canonical name
+ for the system type, which has the form:
+ <SAMP>`<VAR>cpu</VAR>-<VAR>vendor</VAR>-<VAR>os</VAR>'</SAMP>, where <VAR>os</VAR> can be
+ <SAMP>`<VAR>system</VAR>'</SAMP> or <SAMP>`<VAR>kernel</VAR>-<VAR>system</VAR>'</SAMP>
+
+
+ <P>
+ @command{configure} can usually guess the canonical name for the type of
+ system it's running on. To do so it runs a script called
+ @command{config.guess}, which infers the name using the <CODE>uname</CODE>
+ command or symbols predefined by the C preprocessor.
+
+
+ <P>
+ Alternately, the user can specify the system type with command line
+ arguments to @command{configure}. Doing so is necessary when
+ cross-compiling. In the most complex case of cross-compiling, three
+ system types are involved. The options to specify them are:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--build=<VAR>build-type</VAR>}
+ <DD>
+ the type of system on which the package is being configured and
+ compiled. It defaults to the result of running @command{config.guess}.
+
+ <DT>@option{--host=<VAR>host-type</VAR>}
+ <DD>
+ <A NAME="IDX751"></A>
+ the type of system on which the package will run. By default it is the
+ same as the build machine. Specifying it enables the cross-compilation
+ mode.
+
+ <DT>@option{--target=<VAR>target-type</VAR>}
+ <DD>
+ the type of system for which any compiler tools in the package will
+ produce code (rarely needed). By default, it is the same as host.
+ </DL>
+
+ <P>
+ If you mean to override the result of @command{config.guess}, use
+ @option{--build}, not @option{--host}, since the latter enables
+ cross-compilation. For historical reasons, passing @option{--host} also
+ changes the build type. Therefore, whenever you specify <CODE>--host</CODE>,
+ be sure to specify <CODE>--build</CODE> too. This will be fixed in the
+ future.
+
+
+
+ <PRE>
+ ./configure --build=i686-pc-linux-gnu --host=m68k-coff
+ </PRE>
+
+ <P>
+ will enter cross-compilation mode, but @command{configure} will fail if it
+ can't run the code generated by the specified compiler if you configure
+ as follows:
+
+
+
+ <PRE>
+ ./configure CC=m68k-coff-gcc
+ </PRE>
+
+ <P>
+ <A NAME="IDX752"></A>
+ @command{configure} recognizes short aliases for many system types; for
+ example, <SAMP>`decstation'</SAMP> can be used instead of
+ <SAMP>`mips-dec-ultrix4.2'</SAMP>. @command{configure} runs a script called
+ @command{config.sub} to canonicalize system type aliases.
+
+
+ <P>
+ This section deliberately omits the description of the obsolete
+ interface, see section <A HREF="autoconf.html#SEC160">Hosts and Cross-Compilation</A>.
+
+
+
+
+ <H2><A NAME="SEC123" HREF="autoconf_toc.html#TOC123">Getting the Canonical System Type</A></H2>
+
+ <P>
+ The following macros make the system type available to @command{configure}
+ scripts.
+
+
+ <P>
+ <A NAME="IDX753"></A>
+ <A NAME="IDX754"></A>
+ <A NAME="IDX755"></A>
+
+
+ <P>
+ The variables <SAMP>`build_alias'</SAMP>, <SAMP>`host_alias'</SAMP>, and
+ <SAMP>`target_alias'</SAMP> are always exactly the arguments of @option{--build},
+ @option{--host}, and @option{--target}; in particular, they are left empty
+ if the user did not use them, even if the corresponding
+ <CODE>AC_CANONICAL</CODE> macro was run. Any configure script may use these
+ variables anywhere. These are the variables that should be used when in
+ interaction with the user.
+
+
+ <P>
+ If you need to recognize some special environments based on their system
+ type, run the following macros to get canonical system names. These
+ variables are not set before the macro call.
+
+
+ <P>
+ If you use these macros, you must distribute @command{config.guess} and
+ @command{config.sub} along with your source code. See section <A HREF="autoconf.html#SEC19">Outputting Files</A>, for
+ information about the <CODE>AC_CONFIG_AUX_DIR</CODE> macro which you can use
+ to control in which directory @command{configure} looks for those scripts.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CANONICAL_BUILD</B>
+ <DD><A NAME="IDX756"></A>
+ <A NAME="IDX757"></A>
+ <A NAME="IDX758"></A>
+ <A NAME="IDX759"></A>
+ <A NAME="IDX760"></A>
+ <A NAME="IDX761"></A>
+ 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>
+ If @option{--build} was specified, then <CODE>build</CODE> is the
+ canonicalization of <CODE>build_alias</CODE> by @command{config.sub},
+ otherwise it is determined by the shell script @command{config.guess}.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CANONICAL_HOST</B>
+ <DD><A NAME="IDX762"></A>
+ <A NAME="IDX763"></A>
+ <A NAME="IDX764"></A>
+ <A NAME="IDX765"></A>
+ <A NAME="IDX766"></A>
+ <A NAME="IDX767"></A>
+ 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>
+ If @option{--host} was specified, then <CODE>host</CODE> is the
+ canonicalization of <CODE>host_alias</CODE> by @command{config.sub},
+ otherwise it defaults to <CODE>build</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CANONICAL_TARGET</B>
+ <DD><A NAME="IDX768"></A>
+ <A NAME="IDX769"></A>
+ <A NAME="IDX770"></A>
+ <A NAME="IDX771"></A>
+ <A NAME="IDX772"></A>
+ <A NAME="IDX773"></A>
+ 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>
+ If @option{--target} was specified, then <CODE>target</CODE> is the
+ canonicalization of <CODE>target_alias</CODE> by @command{config.sub},
+ otherwise it defaults to <CODE>host</CODE>.
+ </DL>
+
+
+ <P>
+ Note that there can be artifacts due to the backward compatibility
+ code. See section <A HREF="autoconf.html#SEC160">Hosts and Cross-Compilation</A>, for more.
+
+
+
+
+ <H2><A NAME="SEC124" HREF="autoconf_toc.html#TOC124">Using the System Type</A></H2>
+
+ <P>
+ How do you use a canonical system type? Usually, you use it in one or
+ more <CODE>case</CODE> statements in <TT>`configure.ac'</TT> to select
+ system-specific C files. Then, using <CODE>AC_CONFIG_LINKS</CODE>, link those
+ files which have names based on the system name, to generic names, such
+ as <TT>`host.h'</TT> or <TT>`target.c'</TT> (see section <A HREF="autoconf.html#SEC32">Creating Configuration Links</A>). The
+ <CODE>case</CODE> statement patterns can use shell wild cards to group several
+ cases together, like in this fragment:
+
+
+
+ <PRE>
+ case $target in
+ i386-*-mach* | i386-*-gnu*)
+ obj_format=aout emulation=mach bfd_gas=yes ;;
+ i960-*-bout) obj_format=bout ;;
+ esac
+ </PRE>
+
+ <P>
+ and later in <TT>`configure.ac'</TT>, use:
+
+
+
+ <PRE>
+ AC_CONFIG_LINKS(host.h:config/$machine.h
+ object.h:config/$obj_format.h)
+ </PRE>
+
+ <P>
+ Note that the above example uses <CODE>$target</CODE> because it's taken from
+ a tool which can be built on some architecture (<CODE>$build</CODE>), run on
+ another (<CODE>$host</CODE>), but yet handle data for a third architecture
+ (<CODE>$target</CODE>). Such tools are usually part of a compiler suite, they
+ generate code for a specific <CODE>$target</CODE>.
+
+
+ <P>
+ However <CODE>$target</CODE> should be meaningless for most packages. If you
+ want to base a decision on the system where your program will be run,
+ make sure you use the <CODE>$host</CODE> variable, as in the following
+ excerpt:
+
+
+
+ <PRE>
+ case $host in
+ *-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
+ MUMBLE_INIT="mumble.ini"
+ ;;
+ *)
+ MUMBLE_INIT=".mumbleinit"
+ ;;
+ esac
+ AC_SUBST([MUMBLE_INIT])
+ </PRE>
+
+ <P>
+ You can also use the host system type to find cross-compilation tools.
+ See section <A HREF="autoconf.html#SEC41">Generic Program and File Checks</A>, for information about the <CODE>AC_CHECK_TOOL</CODE>
+ macro which does that.
+
+
+
+
+ <H1><A NAME="SEC125" HREF="autoconf_toc.html#TOC125">Site Configuration</A></H1>
+
+ <P>
+ @command{configure} scripts support several kinds of local configuration
+ decisions. There are ways for users to specify where external software
+ packages are, include or exclude optional features, install programs
+ under modified names, and set default values for @command{configure}
+ options.
+
+
+
+
+ <H2><A NAME="SEC126" HREF="autoconf_toc.html#TOC126">Working With External Software</A></H2>
+
+ <P>
+ Some packages require, or can optionally use, other software packages
+ that are already installed. The user can give @command{configure}
+ command line options to specify which such external software to use.
+ The options have one of these forms:
+
+
+
+ <PRE>
+ --with-<VAR>package</VAR>[=<VAR>arg</VAR>]
+ --without-<VAR>package</VAR>
+ </PRE>
+
+ <P>
+ For example, @option{--with-gnu-ld} means work with the GNU linker
+ instead of some other linker. @option{--with-x} means work with The X
+ Window System.
+
+
+ <P>
+ The user can give an argument by following the package name with
+ <SAMP>`='</SAMP> and the argument. Giving an argument of <SAMP>`no'</SAMP> is for
+ packages that are used by default; it says to <EM>not</EM> use the
+ package. An argument that is neither <SAMP>`yes'</SAMP> nor <SAMP>`no'</SAMP> could
+ include a name or number of a version of the other package, to specify
+ more precisely which other package this program is supposed to work
+ with. If no argument is given, it defaults to <SAMP>`yes'</SAMP>.
+ @option{--without-<VAR>package</VAR>} is equivalent to
+ @option{--with-<VAR>package</VAR>=no}.
+
+
+ <P>
+ @command{configure} scripts do not complain about
+ @option{--with-<VAR>package</VAR>} options that they do not support. This
+ behavior permits configuring a source tree containing multiple packages
+ with a top-level @command{configure} script when the packages support
+ different options, without spurious error messages about options that
+ some of the packages support. An unfortunate side effect is that option
+ spelling errors are not diagnosed. No better approach to this problem
+ has been suggested so far.
+
+
+ <P>
+ For each external software package that may be used, <TT>`configure.ac'</TT>
+ should call <CODE>AC_ARG_WITH</CODE> to detect whether the @command{configure}
+ user asked to use it. Whether each package is used or not by default,
+ and which arguments are valid, is up to you.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ARG_WITH</B> <I>(<VAR>package</VAR>, <VAR>help-string</VAR>, @ovar{action-if-given}, @ovar{action-if-not-given})</I>
+ <DD><A NAME="IDX774"></A>
+ <A NAME="IDX775"></A>
+ If the user gave @command{configure} the option @option{--with-<VAR>package</VAR>}
+ or @option{--without-<VAR>package</VAR>}, 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 and dashes.
+
+
+ <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 <CODE>with_<VAR>package</VAR></CODE>,
+ with any @option{-} characters changed into <SAMP>`_'</SAMP>. You may use that
+ variable instead, if you wish.
+
+
+ <P>
+ The argument <VAR>help-string</VAR> is a description of the option that
+ looks like this:
+
+ <PRE>
+ --with-readline support fancy command line editing
+ </PRE>
+
+ <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. You'll need to enclose it in <SAMP>`['</SAMP>
+ and <SAMP>`]'</SAMP> in order to produce the leading spaces.
+
+
+ <P>
+ You should format your <VAR>help-string</VAR> with the macro
+ <CODE>AC_HELP_STRING</CODE> (see section <A HREF="autoconf.html#SEC128">Making Your Help Strings Look Pretty</A>).
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_WITH</B> <I>(<VAR>package</VAR>, <VAR>action-if-given</VAR>, @ovar{action-if-not-given})</I>
+ <DD><A NAME="IDX776"></A>
+ <A NAME="IDX777"></A>
+ This is an obsolete version of <CODE>AC_ARG_WITH</CODE> that does not
+ support providing a help string.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC127" HREF="autoconf_toc.html#TOC127">Choosing Package Options</A></H2>
+
+ <P>
+ If a software package has optional compile-time features, the user can
+ give @command{configure} command line options to specify whether to
+ compile them. The options have one of these forms:
+
+
+
+ <PRE>
+ --enable-<VAR>feature</VAR>[=<VAR>arg</VAR>]
+ --disable-<VAR>feature</VAR>
+ </PRE>
+
+ <P>
+ These options allow users to choose which optional features to build and
+ install. @option{--enable-<VAR>feature</VAR>} options should never make a
+ feature behave differently or cause one feature to replace another.
+ They should only cause parts of the program to be built rather than left
+ out.
+
+
+ <P>
+ The user can give an argument by following the feature name with
+ <SAMP>`='</SAMP> and the argument. Giving an argument of <SAMP>`no'</SAMP> requests
+ that the feature <EM>not</EM> be made available. A feature with an
+ argument looks like @option{--enable-debug=stabs}. If no argument is
+ given, it defaults to <SAMP>`yes'</SAMP>. @option{--disable-<VAR>feature</VAR>} is
+ equivalent to @option{--enable-<VAR>feature</VAR>=no}.
+
+
+ <P>
+ @command{configure} scripts do not complain about
+ @option{--enable-<VAR>feature</VAR>} options that they do not support.
+ This behavior permits configuring a source tree containing multiple
+ packages with a top-level @command{configure} script when the packages
+ support different options, without spurious error messages about options
+ that some of the packages support.
+ An unfortunate side effect is that option spelling errors are not diagnosed.
+ No better approach to this problem has been suggested so far.
+
+
+ <P>
+ For each optional feature, <TT>`configure.ac'</TT> should call
+ <CODE>AC_ARG_ENABLE</CODE> to detect whether the @command{configure} user asked
+ to include it. Whether each feature is included or not by default, and
+ which arguments are valid, is up to you.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ARG_ENABLE</B> <I>(<VAR>feature</VAR>, <VAR>help-string</VAR>, @ovar{action-if-given}, @ovar{action-if-not-given})</I>
+ <DD><A NAME="IDX778"></A>
+ <A NAME="IDX779"></A>
+ If the user gave @command{configure} the option
+ @option{--enable-<VAR>feature</VAR>} or @option{--disable-<VAR>feature</VAR>}, 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 and dashes.
+
+
+ <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
+ <CODE>enable_<VAR>feature</VAR></CODE>, with any @option{-} characters 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>
+ (see section <A HREF="autoconf.html#SEC126">Working With External Software</A>).
+
+
+ <P>
+ You should format your <VAR>help-string</VAR> with the macro
+ <CODE>AC_HELP_STRING</CODE> (see section <A HREF="autoconf.html#SEC128">Making Your Help Strings Look Pretty</A>).
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ENABLE</B> <I>(<VAR>feature</VAR>, <VAR>action-if-given</VAR>, @ovar{action-if-not-given})</I>
+ <DD><A NAME="IDX780"></A>
+ <A NAME="IDX781"></A>
+ This is an obsolete version of <CODE>AC_ARG_ENABLE</CODE> that does not
+ support providing a help string.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC128" HREF="autoconf_toc.html#TOC128">Making Your Help Strings Look Pretty</A></H2>
+
+ <P>
+ Properly formatting the <SAMP>`help strings'</SAMP> which are used in
+ <CODE>AC_ARG_WITH</CODE> (see section <A HREF="autoconf.html#SEC126">Working With External Software</A>) and <CODE>AC_ARG_ENABLE</CODE>
+ (see section <A HREF="autoconf.html#SEC127">Choosing Package Options</A>) can be challenging. Specifically, you want
+ your own <SAMP>`help strings'</SAMP> to line up in the appropriate columns of
+ <SAMP>`configure --help'</SAMP> just like the standard Autoconf <SAMP>`help
+ strings'</SAMP> do. This is the purpose of the <CODE>AC_HELP_STRING</CODE> macro.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HELP_STRING</B> <I>(<VAR>left-hand-side</VAR>, <VAR>right-hand-side</VAR>)</I>
+ <DD><A NAME="IDX782"></A>
+ <A NAME="IDX783"></A>
+
+
+ <P>
+ Expands into an help string that looks pretty when the user executes
+ <SAMP>`configure --help'</SAMP>. It is typically used in <CODE>AC_ARG_WITH</CODE>
+ (see section <A HREF="autoconf.html#SEC126">Working With External Software</A>) or <CODE>AC_ARG_ENABLE</CODE> (see section <A HREF="autoconf.html#SEC127">Choosing Package Options</A>). The following example will make this clearer.
+
+
+
+ <PRE>
+ AC_DEFUN(TEST_MACRO,
+ [AC_ARG_WITH(foo,
+ AC_HELP_STRING([--with-foo],
+ [use foo (default is NO)]),
+ ac_cv_use_foo=$withval, ac_cv_use_foo=no),
+ AC_CACHE_CHECK(whether to use foo,
+ ac_cv_use_foo, ac_cv_use_foo=no)])
+ </PRE>
+
+ <P>
+ Please note that the call to <CODE>AC_HELP_STRING</CODE> is <STRONG>unquoted</STRONG>.
+ Then the last few lines of <SAMP>`configure --help'</SAMP> will appear like
+ this:
+
+
+
+ <PRE>
+ --enable and --with options recognized:
+ --with-foo use foo (default is NO)
+ </PRE>
+
+ <P>
+ The <CODE>AC_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.
+
+
+
+ <PRE>
+ AC_DEFUN(MY_ARG_WITH,
+ [AC_ARG_WITH([$1],
+ AC_HELP_STRING([--with-$1], [use $1 (default is $2)]),
+ ac_cv_use_$1=$withval, ac_cv_use_$1=no),
+ AC_CACHE_CHECK(whether to use $1, ac_cv_use_$1, ac_cv_use_$1=$2)])
+ </PRE>
+
+ </DL>
+
+
+
+ <H2><A NAME="SEC129" HREF="autoconf_toc.html#TOC129">Configuring Site Details</A></H2>
+
+ <P>
+ Some software packages require complex site-specific information. Some
+ examples are host names to use for certain services, company names, and
+ email addresses to contact. Since some configuration scripts generated
+ by Metaconfig ask for such information interactively, people sometimes
+ wonder how to get that information in Autoconf-generated configuration
+ scripts, which aren't interactive.
+
+
+ <P>
+ Such site configuration information should be put in a file that is
+ edited <EM>only by users</EM>, not by programs. The location of the file
+ can either be based on the <CODE>prefix</CODE> variable, or be a standard
+ location such as the user's home directory. It could even be specified
+ by an environment variable. The programs should examine that file at
+ run time, rather than at compile time. Run time configuration is more
+ convenient for users and makes the configuration process simpler than
+ getting the information while configuring. See section `Variables for Installation Directories' in <CITE>GNU Coding Standards</CITE>, for more information on where to put data files.
+
+
+
+
+ <H2><A NAME="SEC130" HREF="autoconf_toc.html#TOC130">Transforming Program Names When Installing</A></H2>
+
+ <P>
+ Autoconf supports changing the names of programs when installing them.
+ In order to use these transformations, <TT>`configure.ac'</TT> must call the
+ macro <CODE>AC_ARG_PROGRAM</CODE>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ARG_PROGRAM</B>
+ <DD><A NAME="IDX784"></A>
+ <A NAME="IDX785"></A>
+ <A NAME="IDX786"></A>
+ Place in output variable <CODE>program_transform_name</CODE> a sequence of
+ <CODE>sed</CODE> commands for changing the names of installed programs.
+
+
+ <P>
+ If any of the options described below are given to @command{configure},
+ program names are transformed accordingly. Otherwise, if
+ <CODE>AC_CANONICAL_TARGET</CODE> has been called and a @option{--target} value
+ is given, the target type followed by a dash is used as a prefix.
+ Otherwise, no program name transformation is done.
+ </DL>
+
+
+
+
+ <H3><A NAME="SEC131" HREF="autoconf_toc.html#TOC131">Transformation Options</A></H3>
+
+ <P>
+ You can specify name transformations by giving @command{configure} these
+ command line options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--program-prefix=<VAR>prefix</VAR>}
+ <DD>
+ prepend <VAR>prefix</VAR> to the names;
+
+ <DT>@option{--program-suffix=<VAR>suffix</VAR>}
+ <DD>
+ append <VAR>suffix</VAR> to the names;
+
+ <DT>@option{--program-transform-name=<VAR>expression</VAR>}
+ <DD>
+ perform <CODE>sed</CODE> substitution <VAR>expression</VAR> on the names.
+ </DL>
+
+
+
+ <H3><A NAME="SEC132" HREF="autoconf_toc.html#TOC132">Transformation Examples</A></H3>
+
+ <P>
+ These transformations are useful with programs that can be part of a
+ cross-compilation development environment. For example, a
+ cross-assembler running on a Sun 4 configured with
+ @option{--target=i960-vxworks} is normally installed as
+ <TT>`i960-vxworks-as'</TT>, rather than <TT>`as'</TT>, which could be confused
+ with a native Sun 4 assembler.
+
+
+ <P>
+ You can force a program name to begin with <TT>`g'</TT>, if you don't want
+ GNU programs installed on your system to shadow other programs with
+ the same name. For example, if you configure GNU <CODE>diff</CODE> with
+ @option{--program-prefix=g}, then when you run <SAMP>`make install'</SAMP> it is
+ installed as <TT>`/usr/local/bin/gdiff'</TT>.
+
+
+ <P>
+ As a more sophisticated example, you could use
+
+
+
+ <PRE>
+ --program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'
+ </PRE>
+
+ <P>
+
+
+ <P>
+ to prepend <SAMP>`g'</SAMP> to most of the program names in a source tree,
+ excepting those like <CODE>gdb</CODE> that already have one and those like
+ <CODE>less</CODE> and <CODE>lesskey</CODE> that aren't GNU programs. (That is
+ assuming that you have a source tree containing those programs that is
+ set up to use this feature.)
+
+
+ <P>
+ One way to install multiple versions of some programs simultaneously is
+ to append a version number to the name of one or both. For example, if
+ you want to keep Autoconf version 1 around for awhile, you can configure
+ Autoconf version 2 using @option{--program-suffix=2} to install the
+ programs as <TT>`/usr/local/bin/autoconf2'</TT>,
+ <TT>`/usr/local/bin/autoheader2'</TT>, etc. Nevertheless, pay attention
+ that only the binaries are renamed, therefore you'd have problems with
+ the library files which might overlap.
+
+
+
+
+ <H3><A NAME="SEC133" HREF="autoconf_toc.html#TOC133">Transformation Rules</A></H3>
+
+ <P>
+ Here is how to use the variable <CODE>program_transform_name</CODE> in a
+ <TT>`Makefile.in'</TT>:
+
+
+
+ <PRE>
+ PROGRAMS = cp ls rm
+ transform = @program_transform_name@
+ install:
+ for p in $(PROGRAMS); do \
+ $(INSTALL_PROGRAM) $$p $(DESTDIR)$(bindir)/`echo $$p | \
+ sed '$(transform)'`; \
+ done
+
+ uninstall:
+ for p in $(PROGRAMS); do \
+ rm -f $(DESTDIR)$(bindir)/`echo $$p | sed '$(transform)'`; \
+ done
+ </PRE>
+
+ <P>
+ It is guaranteed that <CODE>program_transform_name</CODE> is never empty, and
+ that there are no useless separators. Therefore you may safely embed
+ <CODE>program_transform_name</CODE> within a sed program using <SAMP>`;'</SAMP>:
+
+
+
+ <PRE>
+ transform = @program_transform_name@
+ transform_exe = s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/
+ </PRE>
+
+ <P>
+ Whether to do the transformations on documentation files (Texinfo or
+ <CODE>man</CODE>) is a tricky question; there seems to be no perfect answer,
+ due to the several reasons for name transforming. Documentation is not
+ usually particular to a specific architecture, and Texinfo files do not
+ conflict with system documentation. But they might conflict with
+ earlier versions of the same files, and <CODE>man</CODE> pages sometimes do
+ conflict with system documentation. As a compromise, it is probably
+ best to do name transformations on <CODE>man</CODE> pages but not on Texinfo
+ manuals.
+
+
+
+
+ <H2><A NAME="SEC134" HREF="autoconf_toc.html#TOC134">Setting Site Defaults</A></H2>
+
+ <P>
+ Autoconf-generated @command{configure} scripts allow your site to provide
+ default values for some configuration values. You do this by creating
+ site- and system-wide initialization files.
+
+
+ <P>
+ <A NAME="IDX787"></A>
+ If the environment variable @command{CONFIG_SITE} is set, @command{configure}
+ uses its value as the name of a shell script to read. Otherwise, it
+ reads the shell script <TT>`<VAR>prefix</VAR>/share/config.site'</TT> if it exists,
+ then <TT>`<VAR>prefix</VAR>/etc/config.site'</TT> if it exists. Thus,
+ settings in machine-specific files override those in machine-independent
+ ones in case of conflict.
+
+
+ <P>
+ Site files can be arbitrary shell scripts, but only certain kinds of
+ code are really appropriate to be in them. Because @command{configure}
+ reads any cache file after it has read any site files, a site file can
+ define a default cache file to be shared between all Autoconf-generated
+ @command{configure} scripts run on that system (see section <A HREF="autoconf.html#SEC84">Cache Files</A>). If
+ you set a default cache file in a site file, it is a good idea to also
+ set the output variable <CODE>CC</CODE> in that site file, because the cache
+ file is only valid for a particular compiler, but many systems have
+ several available.
+
+
+ <P>
+ You can examine or override the value set by a command line option to
+ @command{configure} in a site file; options set shell variables that have
+ the same names as the options, with any dashes turned into underscores.
+ The exceptions are that @option{--without-} and @option{--disable-} options
+ are like giving the corresponding @option{--with-} or @option{--enable-}
+ option and the value <SAMP>`no'</SAMP>. Thus, @option{--cache-file=localcache}
+ sets the variable <CODE>cache_file</CODE> to the value <SAMP>`localcache'</SAMP>;
+ @option{--enable-warnings=no} or @option{--disable-warnings} sets the variable
+ <CODE>enable_warnings</CODE> to the value <SAMP>`no'</SAMP>; @option{--prefix=/usr} sets the
+ variable <CODE>prefix</CODE> to the value <SAMP>`/usr'</SAMP>; etc.
+
+
+ <P>
+ Site files are also good places to set default values for other output
+ variables, such as <CODE>CFLAGS</CODE>, if you need to give them non-default
+ values: anything you would normally do, repetitively, on the command
+ line. If you use non-default values for <VAR>prefix</VAR> or
+ <VAR>exec_prefix</VAR> (wherever you locate the site file), you can set them
+ in the site file if you specify it with the @command{CONFIG_SITE}
+ environment variable.
+
+
+ <P>
+ You can set some cache values in the site file itself. Doing this is
+ useful if you are cross-compiling, so it is impossible to check features
+ that require running a test program. You could "prime the cache" by
+ setting those values correctly for that system in
+ <TT>`<VAR>prefix</VAR>/etc/config.site'</TT>. To find out the names of the cache
+ variables you need to set, look for shell variables with <SAMP>`_cv_'</SAMP> in
+ their names in the affected @command{configure} scripts, or in the Autoconf
+ M4 source code for those macros.
+
+
+ <P>
+ The cache file is careful to not override any variables set in the site
+ files. Similarly, you should not override command-line options in the
+ site files. Your code should check that variables such as <CODE>prefix</CODE>
+ and <CODE>cache_file</CODE> have their default values (as set near the top of
+ @command{configure}) before changing them.
+
+
+ <P>
+ Here is a sample file <TT>`/usr/share/local/gnu/share/config.site'</TT>. The
+ command <SAMP>`configure --prefix=/usr/share/local/gnu'</SAMP> would read this
+ file (if @command{CONFIG_SITE} is not set to a different file).
+
+
+
+ <PRE>
+ # config.site for configure
+ #
+ # Change some defaults.
+ test "$prefix" = NONE && prefix=/usr/share/local/gnu
+ test "$exec_prefix" = NONE && exec_prefix=/usr/local/gnu
+ test "$sharedstatedir" = '$prefix/com' && sharedstatedir=/var
+ test "$localstatedir" = '$prefix/var' && localstatedir=/var
+
+ # Give Autoconf 2.x generated configure scripts a shared default
+ # cache file for feature test results, architecture-specific.
+ if test "$cache_file" = /dev/null; then
+ cache_file="$prefix/var/config.cache"
+ # A cache file is only valid for one C compiler.
+ CC=gcc
+ fi
+ </PRE>
+
+
+
+ <H1><A NAME="SEC135" HREF="autoconf_toc.html#TOC135">Running @command{configure} Scripts</A></H1>
+ <P>
+ <A NAME="IDX788"></A>
+
+
+ <P>
+ Below are instructions on how to configure a package that uses a
+ @command{configure} script, suitable for inclusion as an <TT>`INSTALL'</TT>
+ file in the package. A plain-text version of <TT>`INSTALL'</TT> which you
+ may use comes with Autoconf.
+
+
+
+
+ <H2><A NAME="SEC136" HREF="autoconf_toc.html#TOC136">Basic Installation</A></H2>
+
+ <P>
+ These are generic installation instructions.
+
+
+ <P>
+ The @command{configure} shell script attempts to guess correct values
+ for various system-dependent variables used during compilation. It uses
+ those values to create a <TT>`Makefile'</TT> in each directory of the
+ package. It may also create one or more <TT>`.h'</TT> files containing
+ system-dependent definitions. Finally, it creates a shell script
+ <TT>`config.status'</TT> that you can run in the future to recreate the
+ current configuration, and a file <TT>`config.log'</TT> containing compiler
+ output (useful mainly for debugging @command{configure}).
+
+
+ <P>
+ It can also use an optional file (typically called <TT>`config.cache'</TT>
+ and enabled with @option{--cache-file=config.cache} or simply
+ @option{-C}) that saves the results of its tests to speed up
+ reconfiguring. (Caching is disabled by default to prevent problems with
+ accidental use of stale cache files.)
+
+
+ <P>
+ If you need to do unusual things to compile the package, please try to
+ figure out how @command{configure} could check whether to do them, and
+ mail diffs or instructions to the address given in the <TT>`README'</TT> so
+ they can be considered for the next release. If you are using the
+ cache, and at some point <TT>`config.cache'</TT> contains results you don't
+ want to keep, you may remove or edit it.
+
+
+ <P>
+ The file <TT>`configure.ac'</TT> (or <TT>`configure.in'</TT>) is used to create
+ <TT>`configure'</TT> by a program called <CODE>autoconf</CODE>. You only need
+ <TT>`configure.ac'</TT> if you want to change it or regenerate
+ <TT>`configure'</TT> using a newer version of <CODE>autoconf</CODE>.
+
+
+ <P>
+ The simplest way to compile this package is:
+
+
+
+ <OL>
+ <LI>
+
+ <CODE>cd</CODE> to the directory containing the package's source code and type
+ <SAMP>`./configure'</SAMP> to configure the package for your system. If you're
+ using <CODE>csh</CODE> on an old version of System V, you might need to type
+ <SAMP>`sh ./configure'</SAMP> instead to prevent <CODE>csh</CODE> from trying to
+ execute @command{configure} itself.
+
+ Running @command{configure} takes awhile. While running, it prints some
+ messages telling which features it is checking for.
+
+ <LI>
+
+ Type <SAMP>`make'</SAMP> to compile the package.
+
+ <LI>
+
+ Optionally, type <SAMP>`make check'</SAMP> to run any self-tests that come with
+ the package.
+
+ <LI>
+
+ Type <SAMP>`make install'</SAMP> to install the programs and any data files and
+ documentation.
+
+ <LI>
+
+ You can remove the program binaries and object files from the source
+ code directory by typing <SAMP>`make clean'</SAMP>. To also remove the files
+ that @command{configure} created (so you can compile the package for a
+ different kind of computer), type <SAMP>`make distclean'</SAMP>. There is also
+ a <SAMP>`make maintainer-clean'</SAMP> target, but that is intended mainly for
+ the package's developers. If you use it, you may have to get all sorts
+ of other programs in order to regenerate files that came with the
+ distribution.
+ </OL>
+
+
+
+ <H2><A NAME="SEC137" HREF="autoconf_toc.html#TOC137">Compilers and Options</A></H2>
+
+ <P>
+ Some systems require unusual options for compilation or linking that the
+ @command{configure} script does not know about. Run @samp{./configure
+ --help} for details on some of the pertinent environment variables.
+
+
+ <P>
+ You can give @command{configure} initial values for variables by setting
+ them in the environment. You can do that on the command line like this:
+
+
+
+ <PRE>
+ ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
+ </PRE>
+
+ <P>
+ See section <A HREF="autoconf.html#SEC143">Defining Variables</A>, for more details.
+
+
+
+
+ <H2><A NAME="SEC138" HREF="autoconf_toc.html#TOC138">Compiling For Multiple Architectures</A></H2>
+
+ <P>
+ You can compile the package for more than one kind of computer at the
+ same time, by placing the object files for each architecture in their
+ own directory. To do this, you must use a version of @command{make}
+ that supports the <CODE>VPATH</CODE> variable, such as GNU @command{make}.
+ @command{cd} to the directory where you want the object files and
+ executables to go and run the @command{configure} script.
+ @command{configure} automatically checks for the source code in the
+ directory that @command{configure} is in and in <TT>`..'</TT>.
+
+
+ <P>
+ If you have to use a @command{make} that does not support the
+ <CODE>VPATH</CODE> variable, you have to compile the package for one
+ architecture at a time in the source code directory. After you have
+ installed the package for one architecture, use <SAMP>`make distclean'</SAMP>
+ before reconfiguring for another architecture.
+
+
+
+
+ <H2><A NAME="SEC139" HREF="autoconf_toc.html#TOC139">Installation Names</A></H2>
+
+ <P>
+ By default, <SAMP>`make install'</SAMP> will install the package's files in
+ <TT>`/usr/local/bin'</TT>, <TT>`/usr/local/man'</TT>, etc. You can specify an
+ installation prefix other than <TT>`/usr/local'</TT> by giving
+ @command{configure} the option @option{--prefix=<VAR>path</VAR>}.
+
+
+ <P>
+ You can specify separate installation prefixes for architecture-specific
+ files and architecture-independent files. If you give
+ @command{configure} the option @option{--exec-prefix=<VAR>path</VAR>}, the
+ package will use <VAR>path</VAR> as the prefix for installing programs and
+ libraries. Documentation and other data files will still use the
+ regular prefix.
+
+
+ <P>
+ In addition, if you use an unusual directory layout you can give options
+ like @option{--bindir=<VAR>path</VAR>} to specify different values for
+ particular kinds of files. Run <SAMP>`configure --help'</SAMP> for a list of
+ the directories you can set and what kinds of files go in them.
+
+
+ <P>
+ If the package supports it, you can cause programs to be installed with
+ an extra prefix or suffix on their names by giving @command{configure}
+ the option @option{--program-prefix=<VAR>PREFIX</VAR>} or
+ @option{--program-suffix=<VAR>SUFFIX</VAR>}.
+
+
+
+
+ <H2><A NAME="SEC140" HREF="autoconf_toc.html#TOC140">Optional Features</A></H2>
+
+ <P>
+ Some packages pay attention to @option{--enable-<VAR>feature</VAR>} options
+ to @command{configure}, where <VAR>feature</VAR> indicates an optional part
+ of the package. They may also pay attention to
+ @option{--with-<VAR>package</VAR>} options, where <VAR>package</VAR> is something
+ like <SAMP>`gnu-as'</SAMP> or <SAMP>`x'</SAMP> (for the X Window System). The
+ <TT>`README'</TT> should mention any @option{--enable-} and @option{--with-}
+ options that the package recognizes.
+
+
+ <P>
+ For packages that use the X Window System, @command{configure} can
+ usually find the X include and library files automatically, but if it
+ doesn't, you can use the @command{configure} options
+ @option{--x-includes=<VAR>dir</VAR>} and @option{--x-libraries=<VAR>dir</VAR>} to
+ specify their locations.
+
+
+
+
+ <H2><A NAME="SEC141" HREF="autoconf_toc.html#TOC141">Specifying the System Type</A></H2>
+
+ <P>
+ There may be some features @command{configure} cannot figure out
+ automatically, but needs to determine by the type of machine the package
+ will run on. Usually, assuming the package is built to be run on the
+ <EM>same</EM> architectures, @command{configure} can figure that out, but
+ if it prints a message saying it cannot guess the machine type, give it
+ the @option{--build=<VAR>type</VAR>} option. <VAR>type</VAR> can either be a
+ short name for the system type, such as <SAMP>`sun4'</SAMP>, or a canonical name
+ which has the form:
+
+
+
+ <PRE>
+ <VAR>cpu</VAR>-<VAR>company</VAR>-<VAR>system</VAR>
+ </PRE>
+
+ <P>
+ where <VAR>system</VAR> can have one of these forms:
+
+
+
+ <PRE>
+ <VAR>os</VAR> <VAR>kernel</VAR>-<VAR>os</VAR>
+ </PRE>
+
+ <P>
+ See the file <TT>`config.sub'</TT> for the possible values of each field.
+ If <TT>`config.sub'</TT> isn't included in this package, then this package
+ doesn't need to know the machine type.
+
+
+ <P>
+ If you are <EM>building</EM> compiler tools for cross-compiling, you
+ should use the @option{--target=<VAR>type</VAR>} option to select the type of
+ system they will produce code for.
+
+
+ <P>
+ If you want to <EM>use</EM> a cross compiler, that generates code for a
+ platform different from the build platform, you should specify the
+ <EM>host</EM> platform (i.e., that on which the generated programs will
+ eventually be run) with @option{--host=<VAR>type</VAR>}.
+
+
+
+
+ <H2><A NAME="SEC142" HREF="autoconf_toc.html#TOC142">Sharing Defaults</A></H2>
+
+ <P>
+ If you want to set default values for @command{configure} scripts to
+ share, you can create a site shell script called <TT>`config.site'</TT> that
+ gives default values for variables like <CODE>CC</CODE>, <CODE>cache_file</CODE>,
+ and <CODE>prefix</CODE>. @command{configure} looks for
+ <TT>`<VAR>prefix</VAR>/share/config.site'</TT> if it exists, then
+ <TT>`<VAR>prefix</VAR>/etc/config.site'</TT> if it exists. Or, you can set the
+ <CODE>CONFIG_SITE</CODE> environment variable to the location of the site
+ script. A warning: not all @command{configure} scripts look for a site
+ script.
+
+
+
+
+ <H2><A NAME="SEC143" HREF="autoconf_toc.html#TOC143">Defining Variables</A></H2>
+
+ <P>
+ Variables not defined in a site shell script can be set in the
+ environment passed to @command{configure}. However, some packages may
+ run configure again during the build, and the customized values of these
+ variables may be lost. In order to avoid this problem, you should set
+ them in the @command{configure} command line, using <SAMP>`VAR=value'</SAMP>.
+ For example:
+
+
+
+ <PRE>
+ ./configure CC=/usr/local2/bin/gcc
+ </PRE>
+
+ <P>
+ will cause the specified gcc to be used as the C compiler (unless it is
+ overridden in the site shell script).
+
+
+
+
+ <H2><A NAME="SEC144" HREF="autoconf_toc.html#TOC144">@command{configure} Invocation</A></H2>
+
+ <P>
+ @command{configure} recognizes the following options to control how it
+ operates.
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the options to @command{configure}, and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version of Autoconf used to generate the @command{configure}
+ script, and exit.
+
+ <DT>@option{--cache-file=<VAR>file</VAR>}
+ <DD>
+ <A NAME="IDX789"></A>
+ Enable the cache: use and save the results of the tests in <VAR>file</VAR>,
+ traditionally <TT>`config.cache'</TT>. <VAR>file</VAR> defaults to
+ <TT>`/dev/null'</TT> to disable caching.
+
+ <DT>@option{--config-cache}
+ <DD>
+ <DT>@option{-C}
+ <DD>
+ Alias for @option{--cache-file=config.cache}.
+
+ <DT>@option{--quiet}
+ <DD>
+ <DT>@option{--silent}
+ <DD>
+ <DT>@option{-q}
+ <DD>
+ Do not print messages saying which checks are being made. To suppress
+ all normal output, redirect it to <TT>`/dev/null'</TT> (any error messages
+ will still be shown).
+
+ <DT>@option{--srcdir=<VAR>dir</VAR>}
+ <DD>
+ Look for the package's source code in directory <VAR>dir</VAR>. Usually
+ @command{configure} can determine that directory automatically.
+ </DL>
+
+ <P>
+ @command{configure} also accepts some other, not widely useful, options.
+ Run <SAMP>`configure --help'</SAMP> for more details.
+
+
+
+
+ <H1><A NAME="SEC145" HREF="autoconf_toc.html#TOC145">Recreating a Configuration</A></H1>
+ <P>
+ <A NAME="IDX790"></A>
+
+
+ <P>
+ The @command{configure} script creates a file named <TT>`config.status'</TT>,
+ which actually configures, <EM>instantiates</EM>, the template files. It
+ also records the configuration options that were specified when the
+ package was last configured in case reconfiguring is needed.
+
+
+ <P>
+ Synopsis:
+
+ <PRE>
+ ./config.status <VAR>option</VAR>... [<VAR>file</VAR>...]
+ </PRE>
+
+ <P>
+ It configures the <VAR>files</VAR>, if none are specified, all the templates
+ are instantiated. The files must be specified without their
+ dependencies, as in
+
+
+
+ <PRE>
+ ./config.status foobar
+ </PRE>
+
+ <P>
+ not
+
+
+
+ <PRE>
+ ./config.status foobar:foo.in:bar.in
+ </PRE>
+
+ <P>
+ The supported <VAR>option</VAR>s are:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options, the list of the template
+ files and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+
+ <DT>@option{--debug}
+ <DD>
+ <DT>@option{-d}
+ <DD>
+ Don't remove the temporary files.
+
+ <DT>@option{--file=<VAR>file</VAR>[:<VAR>template</VAR>]}
+ <DD>
+ Require that <VAR>file</VAR> be instantiated as if
+ <SAMP>`AC_CONFIG_FILES(<VAR>file</VAR>:<VAR>template</VAR>)'</SAMP> was used. Both
+ <VAR>file</VAR> and <VAR>template</VAR> may be <SAMP>`-'</SAMP> in which case the standard
+ output and/or standard input, respectively, is used. If a
+ <VAR>template</VAR> filename is relative, it is first looked for in the build
+ tree, and then in the source tree. See section <A HREF="autoconf.html#SEC20">Taking Configuration Actions</A>, for
+ more details.
+
+ This option and the following ones provide one way for separately
+ distributed packages to share the values computed by @command{configure}.
+ Doing so can be useful if some of the packages need a superset of the
+ features that one of them, perhaps a common library, does. These
+ options allow a <TT>`config.status'</TT> file to create files other than the
+ ones that its <TT>`configure.ac'</TT> specifies, so it can be used for a
+ different package.
+
+ <DT>@option{--header=<VAR>file</VAR>[:<VAR>template</VAR>]}
+ <DD>
+ Same as @option{--file} above, but with <SAMP>`AC_CONFIG_HEADERS'</SAMP>.
+
+ <DT>@option{--recheck}
+ <DD>
+ Ask <TT>`config.status'</TT> to update itself and exit (no instantiation).
+ This option is useful if you change @command{configure}, so that the
+ results of some tests might be different from the previous run. The
+ @option{--recheck} option re-runs @command{configure} with the same arguments
+ you used before, plus the @option{--no-create} option, which prevents
+ @command{configure} from running <TT>`config.status'</TT> and creating
+ <TT>`Makefile'</TT> and other files, and the @option{--no-recursion} option,
+ which prevents @command{configure} from running other @command{configure}
+ scripts in subdirectories. (This is so other <TT>`Makefile'</TT> rules can
+ run <TT>`config.status'</TT> when it changes; see section <A HREF="autoconf.html#SEC26">Automatic Remaking</A>,
+ for an example).
+ </DL>
+
+ <P>
+ <TT>`config.status'</TT> checks several optional environment variables that
+ can alter its behavior:
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CONFIG_SHELL</B>
+ <DD><A NAME="IDX791"></A>
+ <A NAME="IDX792"></A>
+ The shell with which to run @command{configure} for the @option{--recheck}
+ option. It must be Bourne-compatible. The default is a shell that
+ supports @env{LINENO} if available, and <TT>`/bin/sh'</TT> otherwise.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CONFIG_STATUS</B>
+ <DD><A NAME="IDX793"></A>
+ <A NAME="IDX794"></A>
+ The file name to use for the shell script that records the
+ configuration. The default is <TT>`./config.status'</TT>. This variable is
+ useful when one package uses parts of another and the @command{configure}
+ scripts shouldn't be merged because they are maintained separately.
+ </DL>
+
+
+ <P>
+ You can use <TT>`./config.status'</TT> in your Makefiles. For example, in
+ the dependencies given above (see section <A HREF="autoconf.html#SEC26">Automatic Remaking</A>),
+ <TT>`config.status'</TT> is run twice when <TT>`configure.ac'</TT> has changed.
+ If that bothers you, you can make each run only regenerate the files for
+ that rule:
+
+ <PRE>
+ config.h: stamp-h
+ stamp-h: config.h.in config.status
+ ./config.status config.h
+ echo > stamp-h
+
+ Makefile: Makefile.in config.status
+ ./config.status Makefile
+ </PRE>
+
+ <P>
+ The calling convention of <TT>`config.status'</TT> has changed, see
+ section <A HREF="autoconf.html#SEC147">Obsolete <TT>`config.status'</TT> Invocation</A>, for details.
+
+
+
+
+ <H1><A NAME="SEC146" HREF="autoconf_toc.html#TOC146">Obsolete Constructs</A></H1>
+
+ <P>
+ Autoconf changes, and throughout the years some constructs are obsoleted.
+ Most of the changes involve the macros, but the tools themselves, or
+ even some concepts, are now considered obsolete.
+
+
+ <P>
+ You may completely skip this chapter if you are new to Autoconf, its
+ intention is mainly to help maintainers updating their packages by
+ understanding how to move to more modern constructs.
+
+
+
+
+ <H2><A NAME="SEC147" HREF="autoconf_toc.html#TOC147">Obsolete <TT>`config.status'</TT> Invocation</A></H2>
+
+ <P>
+ <TT>`config.status'</TT> now supports arguments to specify the files to
+ instantiate, see section <A HREF="autoconf.html#SEC145">Recreating a Configuration</A>, for more details.
+ Before, environment variables had to be used.
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CONFIG_COMMANDS</B>
+ <DD><A NAME="IDX795"></A>
+ <A NAME="IDX796"></A>
+ The tags of the commands to execute. The default is the arguments given
+ to <CODE>AC_OUTPUT</CODE> and <CODE>AC_CONFIG_COMMANDS</CODE> in
+ <TT>`configure.ac'</TT>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CONFIG_FILES</B>
+ <DD><A NAME="IDX797"></A>
+ <A NAME="IDX798"></A>
+ The files in which to perform <SAMP>`@<VAR>variable</VAR>@'</SAMP> substitutions.
+ The default is the arguments given to <CODE>AC_OUTPUT</CODE> and
+ <CODE>AC_CONFIG_FILES</CODE> in <TT>`configure.ac'</TT>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CONFIG_HEADERS</B>
+ <DD><A NAME="IDX799"></A>
+ <A NAME="IDX800"></A>
+ The files in which to substitute C <CODE>#define</CODE> statements. The
+ default is the arguments given to <CODE>AC_CONFIG_HEADERS</CODE>; if that
+ macro was not called, <TT>`config.status'</TT> ignores this variable.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Variable:</U> <B>CONFIG_LINKS</B>
+ <DD><A NAME="IDX801"></A>
+ <A NAME="IDX802"></A>
+ The symbolic links to establish. The default is the arguments given to
+ <CODE>AC_CONFIG_LINKS</CODE>; if that macro was not called,
+ <TT>`config.status'</TT> ignores this variable.
+ </DL>
+
+
+ <P>
+ In section <A HREF="autoconf.html#SEC145">Recreating a Configuration</A>, using this old interface, the example
+ would be:
+
+
+
+ <PRE>
+ config.h: stamp-h
+ stamp-h: config.h.in config.status
+ CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_FILES= \
+ CONFIG_HEADERS=config.h ./config.status
+ echo > stamp-h
+
+ Makefile: Makefile.in config.status
+ CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \
+ CONFIG_FILES=Makefile ./config.status
+ </PRE>
+
+ <P>
+ (If <TT>`configure.ac'</TT> does not call <CODE>AC_CONFIG_HEADERS</CODE>, there is
+ no need to set @command{CONFIG_HEADERS} in the <CODE>make</CODE> rules, equally
+ for @command{CONFIG_COMMANDS} etc.)
+
+
+
+
+ <H2><A NAME="SEC148" HREF="autoconf_toc.html#TOC148"><TT>`acconfig.h'</TT></A></H2>
+
+ <P>
+ <A NAME="IDX803"></A>
+ <A NAME="IDX804"></A>
+ <A NAME="IDX805"></A>
+
+
+ <P>
+ In order to produce <TT>`config.h.in'</TT>, @command{autoheader} needs to
+ build or to find templates for each symbol. Modern releases of Autoconf
+ use <CODE>AH_VERBATIM</CODE> and <CODE>AH_TEMPLATE</CODE> (see section <A HREF="autoconf.html#SEC30">Autoheader Macros</A>), but in older releases a file, <TT>`acconfig.h'</TT>, contained the
+ list of needed templates. @command{autoheader} copies comments and
+ <CODE>#define</CODE> and <CODE>#undef</CODE> statements from <TT>`acconfig.h'</TT> in
+ the current directory, if present. This file used to be mandatory if
+ you <CODE>AC_DEFINE</CODE> any additional symbols.
+
+
+ <P>
+ Modern releases of Autoconf also provide <CODE>AH_TOP</CODE> and
+ <CODE>AH_BOTTOM</CODE> if you need to prepend/append some information to
+ <TT>`config.h.in'</TT>. Ancient versions of Autoconf had a similar feature:
+ if <TT>`./acconfig.h'</TT> contains the string <SAMP>`@TOP@'</SAMP>,
+ @command{autoheader} copies the lines before the line containing
+ <SAMP>`@TOP@'</SAMP> into the top of the file that it generates. Similarly,
+ if <TT>`./acconfig.h'</TT> contains the string <SAMP>`@BOTTOM@'</SAMP>,
+ @command{autoheader} copies the lines after that line to the end of the
+ file it generates. Either or both of those strings may be omitted. An
+ even older alternate way to produce the same effect in jurasik versions
+ of Autoconf is to create the files <TT>`<VAR>file</VAR>.top'</TT> (typically
+ <TT>`config.h.top'</TT>) and/or <TT>`<VAR>file</VAR>.bot'</TT> in the current
+ directory. If they exist, @command{autoheader} copies them to the
+ beginning and end, respectively, of its output.
+
+
+ <P>
+ In former versions of Autoconf, the files used in preparing a software
+ package for distribution were:
+
+ <PRE>
+ configure.ac --. .------> autoconf* -----> configure
+ +---+
+ [aclocal.m4] --+ `---.
+ [acsite.m4] ---' |
+ +--> [autoheader*] -> [config.h.in]
+ [acconfig.h] ----. |
+ +-----'
+ [config.h.top] --+
+ [config.h.bot] --'
+ </PRE>
+
+ <P>
+ Use only the <CODE>AH_</CODE> macros, <TT>`configure.ac'</TT> should be
+ self-contained, and should not depend upon <TT>`acconfig.h'</TT> etc.
+
+
+
+
+ <H2><A NAME="SEC149" HREF="autoconf_toc.html#TOC149">Using @command{autoupdate} to Modernize <TT>`configure.ac'</TT></A></H2>
+ <P>
+ <A NAME="IDX806"></A>
+
+
+ <P>
+ The @command{autoupdate} program updates a <TT>`configure.ac'</TT> file that
+ calls Autoconf macros by their old names to use the current macro names.
+ In version 2 of Autoconf, most of the macros were renamed to use a more
+ uniform and descriptive naming scheme. See section <A HREF="autoconf.html#SEC103">Macro Names</A>, for a
+ description of the new scheme. Although the old names still work
+ (see section <A HREF="autoconf.html#SEC150">Obsolete Macros</A>, for a list of the old macros and the corresponding
+ new names), you can make your <TT>`configure.ac'</TT> files more readable
+ and make it easier to use the current Autoconf documentation if you
+ update them to use the new macro names.
+
+
+ <P>
+ <A NAME="IDX807"></A>
+ If given no arguments, @command{autoupdate} updates <TT>`configure.ac'</TT>,
+ backing up the original version with the suffix <TT>`~'</TT> (or the value
+ of the environment variable <CODE>SIMPLE_BACKUP_SUFFIX</CODE>, if that is
+ set). If you give @command{autoupdate} an argument, it reads that file
+ instead of <TT>`configure.ac'</TT> and writes the updated file to the
+ standard output.
+
+
+ <P>
+ @command{autoupdate} accepts the following options:
+
+
+ <DL COMPACT>
+
+ <DT>@option{--help}
+ <DD>
+ <DT>@option{-h}
+ <DD>
+ Print a summary of the command line options and exit.
+
+ <DT>@option{--version}
+ <DD>
+ <DT>@option{-V}
+ <DD>
+ Print the version number of Autoconf and exit.
+
+ <DT>@option{--verbose}
+ <DD>
+ <DT>@option{-v}
+ <DD>
+ Report processing steps.
+
+ <DT>@option{--debug}
+ <DD>
+ <DT>@option{-d}
+ <DD>
+ Don't remove the temporary files.
+
+ <DT>@option{--force}
+ <DD>
+ <DT>@option{-f}
+ <DD>
+ Force the update even if the file has not changed. Disregard the cache.
+
+ <DT>@option{--include=<VAR>dir</VAR>}
+ <DD>
+ <DT>@option{-I <VAR>dir</VAR>}
+ <DD>
+ Also look for input files in <VAR>dir</VAR>. Multiple invocations accumulate.
+ Directories are browsed from last to first.
+ </DL>
+
+
+
+ <H2><A NAME="SEC150" HREF="autoconf_toc.html#TOC150">Obsolete Macros</A></H2>
+
+ <P>
+ Several macros are obsoleted in Autoconf, for various reasons (typically
+ they failed to quote properly, couldn't be extended for more recent
+ issues etc.). They are still supported, but deprecated: their use
+ should be avoided.
+
+
+ <P>
+ During the jump from Autoconf version 1 to version 2, most of the
+ macros were renamed to use a more uniform and descriptive naming scheme,
+ but their signature did not change. See section <A HREF="autoconf.html#SEC103">Macro Names</A>, for a
+ description of the new naming scheme. Below, there is just the mapping
+ from old names to new names for these macros, the reader is invited to
+ refer to the definition of the new macro for the signature and the
+ description.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ALLOCA</B>
+ <DD><A NAME="IDX808"></A>
+ <A NAME="IDX809"></A>
+ <CODE>AC_FUNC_ALLOCA</CODE>
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ARG_ARRAY</B>
+ <DD><A NAME="IDX810"></A>
+ <A NAME="IDX811"></A>
+ removed because of limited usefulness
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_C_CROSS</B>
+ <DD><A NAME="IDX812"></A>
+ <A NAME="IDX813"></A>
+ This macro is obsolete; it does nothing.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CANONICAL_SYSTEM</B>
+ <DD><A NAME="IDX814"></A>
+ <A NAME="IDX815"></A>
+ Determine the system type and set output variables to the names of the
+ canonical system types. See section <A HREF="autoconf.html#SEC123">Getting the Canonical System Type</A>, for details about the
+ variables this macro sets.
+
+
+ <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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHAR_UNSIGNED</B>
+ <DD><A NAME="IDX816"></A>
+ <A NAME="IDX817"></A>
+ <CODE>AC_C_CHAR_UNSIGNED</CODE>
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECK_TYPE</B> <I>(<VAR>type</VAR>, <VAR>default</VAR>)</I>
+ <DD><A NAME="IDX818"></A>
+ <A NAME="IDX819"></A>
+ Autoconf, up to 2.13, used to provide this version of
+ <CODE>AC_CHECK_TYPE</CODE>, deprecated because of its flaws. Firstly, although
+ it is a member of the <CODE>CHECK</CODE> clan, singular sub-family, it does
+ more than just checking. Second, missing types are not
+ <CODE>typedef</CODE>'d, they are <CODE>#define</CODE>'d, which can lead to
+ incompatible code in the case of pointer types.
+
+
+ <P>
+ This use of <CODE>AC_CHECK_TYPE</CODE> is obsolete and discouraged, see
+ section <A HREF="autoconf.html#SEC59">Generic Type Checks</A>, for the description of the current macro.
+
+
+ <P>
+ If the type <VAR>type</VAR> is not defined, define it to be the C (or C++)
+ builtin type <VAR>default</VAR>; e.g., <SAMP>`short'</SAMP> or <SAMP>`unsigned'</SAMP>.
+
+
+ <P>
+ This macro is equivalent to:
+
+
+
+ <PRE>
+ AC_CHECK_TYPE([<VAR>type</VAR>],
+ [AC_DEFINE([<VAR>type</VAR>], [<VAR>default</VAR>],
+ [Define to `<VAR>default</VAR>' if <sys/types.h>
+ does not define.])])
+ </PRE>
+
+ <P>
+ In order to keep backward compatibility, the two versions of
+ <CODE>AC_CHECK_TYPE</CODE> are implemented, selected by a simple heuristics:
+
+
+
+ <OL>
+ <LI>
+
+ If there are three or four arguments, the modern version is used.
+
+ <LI>
+
+ If the second argument appears to be a C or C++ type, then the
+ obsolete version is used. This happens if the argument is a C or C++
+ <EM>builtin</EM> type or a C identifier ending in <SAMP>`_t'</SAMP>, optionally
+ followed by one of <SAMP>`[(* '</SAMP> and then by a string of zero or more
+ characters taken from the set <SAMP>`[]()* _a-zA-Z0-9'</SAMP>.
+
+ <LI>
+
+ If the second argument is spelled with the alphabet of valid C and C++
+ types, the user is warned and the modern version is used.
+
+ <LI>
+
+ Otherwise, the modern version is used.
+ </OL>
+
+ <P>
+ You are encouraged either to use a valid builtin type, or to use the
+ equivalent modern code (see above), or better yet, to use
+ <CODE>AC_CHECK_TYPES</CODE> together with
+
+
+
+ <PRE>
+ #if !HAVE_LOFF_T
+ typedef loff_t off_t;
+ #endif
+ </PRE>
+
+ </DL>
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CHECKING</B> <I>(<VAR>feature-description</VAR>)</I>
+ <DD><A NAME="IDX820"></A>
+ <A NAME="IDX821"></A>
+ Same as <SAMP>`AC_MSG_NOTICE([checking <VAR>feature-description</VAR>...]'</SAMP>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_COMPILE_CHECK</B> <I>(<VAR>echo-text</VAR>, <VAR>includes</VAR>, <VAR>function-body</VAR>, <VAR>action-if-found</VAR>, @ovar{action-if-not-found})</I>
+ <DD><A NAME="IDX822"></A>
+ <A NAME="IDX823"></A>
+ This is an obsolete version of <CODE>AC_TRY_LINK</CODE> (see section <A HREF="autoconf.html#SEC71">Examining Libraries</A>), 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 (see section <A HREF="autoconf.html#SEC86">Printing Messages</A>).
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CONST</B>
+ <DD><A NAME="IDX824"></A>
+ <A NAME="IDX825"></A>
+ <CODE>AC_C_CONST</CODE>
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CROSS_CHECK</B>
+ <DD><A NAME="IDX826"></A>
+ <A NAME="IDX827"></A>
+ Same as <CODE>AC_C_CROSS</CODE>, which is obsolete too, and does nothing
+ <CODE>:-)</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_CYGWIN</B>
+ <DD><A NAME="IDX828"></A>
+ <A NAME="IDX829"></A>
+ 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>. As a matter of fact this macro is defined as:
+
+
+
+ <PRE>
+ AC_REQUIRE([AC_CANONICAL_HOST])[]dnl
+ case $host_os in
+ *cygwin* ) CYGWIN=yes;;
+ * ) CYGWIN=no;;
+ esac
+ </PRE>
+
+ <P>
+ Beware that the variable <CODE>CYGWIN</CODE> has a very special meaning when
+ running CygWin32, and should not be changed. That's yet another reason
+ not to use this macro.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_DECL_YYTEXT</B>
+ <DD><A NAME="IDX830"></A>
+ <A NAME="IDX831"></A>
+ Does nothing, now integrated in <CODE>AC_PROG_LEX</CODE>.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AC_DIR_HEADER</B>
+ <DD><A NAME="IDX832"></A>
+ <A NAME="IDX833"></A>
+ <A NAME="IDX834"></A>
+ <A NAME="IDX835"></A>
+ <A NAME="IDX836"></A>
+ <A NAME="IDX837"></A>
+ Like calling <CODE>AC_FUNC_CLOSEDIR_VOID</CODE> and<CODE>AC_HEADER_DIRENT</CODE>,
+ but defines a different set of C preprocessor macros to indicate which
+ header file is found:
+
+
+ <LI>Header </TD><TD> Old Symbol </TD><TD> New Symbol
+
+ <LI><TT>`dirent.h'</TT> </TD><TD> <CODE>DIRENT</CODE> </TD><TD> <CODE>HAVE_DIRENT_H</CODE>
+
+ <LI><TT>`sys/ndir.h'</TT> </TD><TD> <CODE>SYSNDIR</CODE> </TD><TD> <CODE>HAVE_SYS_NDIR_H</CODE>
+
+ <LI><TT>`sys/dir.h'</TT> </TD><TD> <CODE>SYSDIR</CODE> </TD><TD> <CODE>HAVE_SYS_DIR_H</CODE>
+
+ <LI><TT>`ndir.h'</TT> </TD><TD> <CODE>NDIR</CODE> </TD><TD> <CODE>HAVE_NDIR_H</CODE>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_DYNIX_SEQ</B>
+ <DD><A NAME="IDX838"></A>
+ <A NAME="IDX839"></A>
+ If on Dynix/PTX (Sequent UNIX), add @option{-lseq} to output variable
+ <CODE>LIBS</CODE>. This macro used to be defined as
+
+
+ <PRE>
+ AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS")
+ </PRE>
+
+ now it is just <CODE>AC_FUNC_GETMNTENT</CODE>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_EXEEXT</B>
+ <DD><A NAME="IDX840"></A>
+ <A NAME="IDX841"></A>
+ <A NAME="IDX842"></A>
+ 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 Unix and <SAMP>`.exe'</SAMP> if Win32 or OS/2.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_EMXOS2</B>
+ <DD><A NAME="IDX843"></A>
+ <A NAME="IDX844"></A>
+ Similar to <CODE>AC_CYGWIN</CODE> but checks for the EMX environment on OS/2
+ and sets <CODE>EMXOS2</CODE>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ERROR</B>
+ <DD><A NAME="IDX845"></A>
+ <A NAME="IDX846"></A>
+ <CODE>AC_MSG_ERROR</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FIND_X</B>
+ <DD><A NAME="IDX847"></A>
+ <A NAME="IDX848"></A>
+ <CODE>AC_PATH_X</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FIND_XTRA</B>
+ <DD><A NAME="IDX849"></A>
+ <A NAME="IDX850"></A>
+ <CODE>AC_PATH_XTRA</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_CHECK</B>
+ <DD><A NAME="IDX851"></A>
+ <A NAME="IDX852"></A>
+ <CODE>AC_CHECK_FUNC</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_FUNC_WAIT3</B>
+ <DD><A NAME="IDX853"></A>
+ <A NAME="IDX854"></A>
+ <A NAME="IDX855"></A>
+ 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>.
+
+ These days portable programs should use <CODE>waitpid</CODE>, not
+ <CODE>wait3</CODE>, as <CODE>wait3</CODE> is being removed from the Open Group
+ standards, and will not appear in the next revision of POSIX.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_GCC_TRADITIONAL</B>
+ <DD><A NAME="IDX856"></A>
+ <A NAME="IDX857"></A>
+ <CODE>AC_PROG_GCC_TRADITIONAL</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_GETGROUPS_T</B>
+ <DD><A NAME="IDX858"></A>
+ <A NAME="IDX859"></A>
+ <CODE>AC_TYPE_GETGROUPS</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_GETLOADAVG</B>
+ <DD><A NAME="IDX860"></A>
+ <A NAME="IDX861"></A>
+ <CODE>AC_FUNC_GETLOADAVG</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HAVE_FUNCS</B>
+ <DD><A NAME="IDX862"></A>
+ <A NAME="IDX863"></A>
+ <CODE>AC_CHECK_FUNCS</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HAVE_HEADERS</B>
+ <DD><A NAME="IDX864"></A>
+ <A NAME="IDX865"></A>
+ <CODE>AC_CHECK_HEADERS</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HAVE_LIBRARY</B> <I>(<VAR>library</VAR>, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})</I>
+ <DD><A NAME="IDX866"></A>
+ <A NAME="IDX867"></A>
+ 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>, @option{-lfoo}, or <SAMP>`libfoo.a'</SAMP>. In
+ all of those cases, the compiler is passed @option{-lfoo}. However,
+ <VAR>library</VAR> cannot be a shell variable; it must be a literal name.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HAVE_POUNDBANG</B>
+ <DD><A NAME="IDX868"></A>
+ <A NAME="IDX869"></A>
+ <CODE>AC_SYS_INTERPRETER</CODE> (different calling convention)
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_CHECK</B>
+ <DD><A NAME="IDX870"></A>
+ <A NAME="IDX871"></A>
+ <CODE>AC_CHECK_HEADER</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_HEADER_EGREP</B>
+ <DD><A NAME="IDX872"></A>
+ <A NAME="IDX873"></A>
+ <CODE>AC_EGREP_HEADER</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_INIT</B> <I>(<VAR>unique-file-in-source-dir</VAR>)</I>
+ <DD><A NAME="IDX874"></A>
+ <A NAME="IDX875"></A>
+ Formerly <CODE>AC_INIT</CODE> used to have a single argument, and was
+ equivalent to:
+
+
+ <PRE>
+ AC_INIT
+ AC_CONFIG_SRCDIR(<VAR>unique-file-in-source-dir</VAR>)
+ </PRE>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_INLINE</B>
+ <DD><A NAME="IDX876"></A>
+ <A NAME="IDX877"></A>
+ <CODE>AC_C_INLINE</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_INT_16_BITS</B>
+ <DD><A NAME="IDX878"></A>
+ <A NAME="IDX879"></A>
+ <A NAME="IDX880"></A>
+ 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.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_IRIX_SUN</B>
+ <DD><A NAME="IDX881"></A>
+ <A NAME="IDX882"></A>
+ If on IRIX (Silicon Graphics UNIX), add @option{-lsun} 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
+
+
+ <PRE>
+ AC_CHECK_LIB(sun, getmntent, LIBS="-lsun $LIBS")
+ </PRE>
+
+ now it is defined as
+
+
+ <PRE>
+ AC_FUNC_GETMNTENT
+ AC_CHECK_LIB(sun, getpwnam)
+ </PRE>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG_C</B>
+ <DD><A NAME="IDX883"></A>
+ <A NAME="IDX884"></A>
+ Same as <SAMP>`AC_LANG(C)'</SAMP>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG_CPLUSPLUS</B>
+ <DD><A NAME="IDX885"></A>
+ <A NAME="IDX886"></A>
+ Same as <SAMP>`AC_LANG(C++)'</SAMP>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG_FORTRAN77</B>
+ <DD><A NAME="IDX887"></A>
+ <A NAME="IDX888"></A>
+ Same as <SAMP>`AC_LANG(Fortran 77)'</SAMP>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG_RESTORE</B>
+ <DD><A NAME="IDX889"></A>
+ <A NAME="IDX890"></A>
+ 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>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LANG_SAVE</B>
+ <DD><A NAME="IDX891"></A>
+ <A NAME="IDX892"></A>
+ 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.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LINK_FILES</B> <I>(<VAR>source</VAR>..., <VAR>dest</VAR>...)</I>
+ <DD><A NAME="IDX893"></A>
+ <A NAME="IDX894"></A>
+ This is an obsolete version of <CODE>AC_CONFIG_LINKS</CODE>. An updated
+ version of:
+
+
+ <PRE>
+ AC_LINK_FILES(config/$machine.h config/$obj_format.h,
+ host.h object.h)
+ </PRE>
+
+ is:
+
+
+ <PRE>
+ AC_CONFIG_LINKS(host.h:config/$machine.h
+ object.h:config/$obj_format.h)
+ </PRE>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LN_S</B>
+ <DD><A NAME="IDX895"></A>
+ <A NAME="IDX896"></A>
+ <CODE>AC_PROG_LN_S</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LONG_64_BITS</B>
+ <DD><A NAME="IDX897"></A>
+ <A NAME="IDX898"></A>
+ <A NAME="IDX899"></A>
+ 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.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LONG_DOUBLE</B>
+ <DD><A NAME="IDX900"></A>
+ <A NAME="IDX901"></A>
+ <CODE>AC_C_LONG_DOUBLE</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_LONG_FILE_NAMES</B>
+ <DD><A NAME="IDX902"></A>
+ <A NAME="IDX903"></A>
+ <CODE>AC_SYS_LONG_FILE_NAMES</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MAJOR_HEADER</B>
+ <DD><A NAME="IDX904"></A>
+ <A NAME="IDX905"></A>
+ <CODE>AC_HEADER_MAJOR</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MEMORY_H</B>
+ <DD><A NAME="IDX906"></A>
+ <A NAME="IDX907"></A>
+ <A NAME="IDX908"></A>
+ 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>. Adjust your code to depend upon
+ <CODE>HAVE_MEMORY_H</CODE>, not <CODE>NEED_MEMORY_H</CODE>, see See section <A HREF="autoconf.html#SEC37">Standard Symbols</A>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MINGW32</B>
+ <DD><A NAME="IDX909"></A>
+ <A NAME="IDX910"></A>
+ Similar to <CODE>AC_CYGWIN</CODE> but checks for the MingW32 compiler
+ environment and sets <CODE>MINGW32</CODE>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MINUS_C_MINUS_O</B>
+ <DD><A NAME="IDX911"></A>
+ <A NAME="IDX912"></A>
+ <CODE>AC_PROG_CC_C_O</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MMAP</B>
+ <DD><A NAME="IDX913"></A>
+ <A NAME="IDX914"></A>
+ <CODE>AC_FUNC_MMAP</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_MODE_T</B>
+ <DD><A NAME="IDX915"></A>
+ <A NAME="IDX916"></A>
+ <CODE>AC_TYPE_MODE_T</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_OBJEXT</B>
+ <DD><A NAME="IDX917"></A>
+ <A NAME="IDX918"></A>
+ <A NAME="IDX919"></A>
+ 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 Unix, <SAMP>`obj'</SAMP> if Win32. Now the compiler checking macros handle
+ this automatically.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_OBSOLETE</B> <I>(<VAR>this-macro-name</VAR>, @ovar{suggestion})</I>
+ <DD><A NAME="IDX920"></A>
+ <A NAME="IDX921"></A>
+ Make <CODE>m4</CODE> 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>.
+
+ For instance
+
+
+ <PRE>
+ AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl
+ </PRE>
+
+ You are encouraged to use <CODE>AU_DEFUN</CODE> instead, since it gives better
+ services to the user.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_OFF_T</B>
+ <DD><A NAME="IDX922"></A>
+ <A NAME="IDX923"></A>
+ <CODE>AC_TYPE_OFF_T</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_OUTPUT</B> <I>(@ovar{file}..., @ovar{extra-cmds}, @ovar{init-cmds})</I>
+ <DD><A NAME="IDX924"></A>
+ <A NAME="IDX925"></A>
+ The use of <CODE>AC_OUTPUT</CODE> with argument is deprecated, this obsoleted
+ interface is equivalent to:
+
+
+ <PRE>
+ AC_CONFIG_FILES(<VAR>file</VAR>...)
+ AC_CONFIG_COMMANDS([default],
+ <VAR>extra-cmds</VAR>, <VAR>init-cmds</VAR>)
+ AC_OUTPUT
+ </PRE>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_OUTPUT_COMMANDS</B> <I>(<VAR>extra-cmds</VAR>, @ovar{init-cmds})</I>
+ <DD><A NAME="IDX926"></A>
+ <A NAME="IDX927"></A>
+ Specify additional shell commands to run at the end of
+ <TT>`config.status'</TT>, and shell commands to initialize any variables
+ from @command{configure}. This macro may be called multiple times. It is
+ obsolete, replaced by <CODE>AC_CONFIG_COMMANDS</CODE>.
+
+ Here is an unrealistic 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>
+
+ 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, while
+ <CODE>AC_CONFIG_COMMANDS</CODE>. This means that <CODE>AC_CONFIG_COMMANDS</CODE>
+ can safely be given macro calls as arguments:
+
+
+ <PRE>
+ AC_CONFIG_COMMANDS(foo, [my_FOO()])
+ </PRE>
+
+ 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:
+
+
+ <PRE>
+ AC_OUTPUT_COMMANDS([echo "Square brackets: []"])
+ AC_CONFIG_COMMANDS([default], [[echo "Square brackets: []"]])
+ </PRE>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PID_T</B>
+ <DD><A NAME="IDX928"></A>
+ <A NAME="IDX929"></A>
+ <CODE>AC_TYPE_PID_T</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PREFIX</B>
+ <DD><A NAME="IDX930"></A>
+ <A NAME="IDX931"></A>
+ <CODE>AC_PREFIX_PROGRAM</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROGRAMS_CHECK</B>
+ <DD><A NAME="IDX932"></A>
+ <A NAME="IDX933"></A>
+ <CODE>AC_CHECK_PROGS</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROGRAMS_PATH</B>
+ <DD><A NAME="IDX934"></A>
+ <A NAME="IDX935"></A>
+ <CODE>AC_PATH_PROGS</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROGRAM_CHECK</B>
+ <DD><A NAME="IDX936"></A>
+ <A NAME="IDX937"></A>
+ <CODE>AC_CHECK_PROG</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROGRAM_EGREP</B>
+ <DD><A NAME="IDX938"></A>
+ <A NAME="IDX939"></A>
+ <CODE>AC_EGREP_CPP</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_PROGRAM_PATH</B>
+ <DD><A NAME="IDX940"></A>
+ <A NAME="IDX941"></A>
+ <CODE>AC_PATH_PROG</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_REMOTE_TAPE</B>
+ <DD><A NAME="IDX942"></A>
+ <A NAME="IDX943"></A>
+ removed because of limited usefulness
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_RESTARTABLE_SYSCALLS</B>
+ <DD><A NAME="IDX944"></A>
+ <A NAME="IDX945"></A>
+ <CODE>AC_SYS_RESTARTABLE_SYSCALLS</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_RETSIGTYPE</B>
+ <DD><A NAME="IDX946"></A>
+ <A NAME="IDX947"></A>
+ <CODE>AC_TYPE_SIGNAL</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_RSH</B>
+ <DD><A NAME="IDX948"></A>
+ <A NAME="IDX949"></A>
+ Removed because of limited usefulness.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SCO_INTL</B>
+ <DD><A NAME="IDX950"></A>
+ <A NAME="IDX951"></A>
+ <A NAME="IDX952"></A>
+ If on SCO UNIX, add @option{-lintl} to output variable <CODE>LIBS</CODE>. This
+ macro used to
+
+
+ <PRE>
+ AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS")
+ </PRE>
+
+ now it just calls <CODE>AC_FUNC_STRFTIME</CODE> instead.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SETVBUF_REVERSED</B>
+ <DD><A NAME="IDX953"></A>
+ <A NAME="IDX954"></A>
+ <CODE>AC_FUNC_SETVBUF_REVERSED</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SET_MAKE</B>
+ <DD><A NAME="IDX955"></A>
+ <A NAME="IDX956"></A>
+ <CODE>AC_PROG_MAKE_SET</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SIZEOF_TYPE</B>
+ <DD><A NAME="IDX957"></A>
+ <A NAME="IDX958"></A>
+ <CODE>AC_CHECK_SIZEOF</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SIZE_T</B>
+ <DD><A NAME="IDX959"></A>
+ <A NAME="IDX960"></A>
+ <CODE>AC_TYPE_SIZE_T</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STAT_MACROS_BROKEN</B>
+ <DD><A NAME="IDX961"></A>
+ <A NAME="IDX962"></A>
+ <CODE>AC_HEADER_STAT</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STDC_HEADERS</B>
+ <DD><A NAME="IDX963"></A>
+ <A NAME="IDX964"></A>
+ <CODE>AC_HEADER_STDC</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_STRCOLL</B>
+ <DD><A NAME="IDX965"></A>
+ <A NAME="IDX966"></A>
+ <CODE>AC_FUNC_STRCOLL</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ST_BLKSIZE</B>
+ <DD><A NAME="IDX967"></A>
+ <A NAME="IDX968"></A>
+ <CODE>AC_STRUCT_ST_BLKSIZE</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ST_BLOCKS</B>
+ <DD><A NAME="IDX969"></A>
+ <A NAME="IDX970"></A>
+ <CODE>AC_STRUCT_ST_BLOCKS</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_ST_RDEV</B>
+ <DD><A NAME="IDX971"></A>
+ <A NAME="IDX972"></A>
+ <CODE>AC_STRUCT_ST_RDEV</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SYS_RESTARTABLE_SYSCALLS</B>
+ <DD><A NAME="IDX973"></A>
+ <A NAME="IDX974"></A>
+ <A NAME="IDX975"></A>
+ 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 if system calls are restarted in general--it tests whether a
+ signal handler installed with <CODE>signal</CODE> (but not <CODE>sigaction</CODE>)
+ causes system calls to be restarted. It does not test if system calls
+ can be restarted when interrupted by signals that have no handler.
+
+ 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.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_SYS_SIGLIST_DECLARED</B>
+ <DD><A NAME="IDX976"></A>
+ <A NAME="IDX977"></A>
+ <CODE>AC_DECL_SYS_SIGLIST</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TEST_CPP</B>
+ <DD><A NAME="IDX978"></A>
+ <A NAME="IDX979"></A>
+ <CODE>AC_TRY_CPP</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TEST_PROGRAM</B>
+ <DD><A NAME="IDX980"></A>
+ <A NAME="IDX981"></A>
+ <CODE>AC_TRY_RUN</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TIMEZONE</B>
+ <DD><A NAME="IDX982"></A>
+ <A NAME="IDX983"></A>
+ <CODE>AC_STRUCT_TIMEZONE</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_TIME_WITH_SYS_TIME</B>
+ <DD><A NAME="IDX984"></A>
+ <A NAME="IDX985"></A>
+ <CODE>AC_HEADER_TIME</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_UID_T</B>
+ <DD><A NAME="IDX986"></A>
+ <A NAME="IDX987"></A>
+ <CODE>AC_TYPE_UID_T</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_UNISTD_H</B>
+ <DD><A NAME="IDX988"></A>
+ <A NAME="IDX989"></A>
+ Same as <SAMP>`AC_CHECK_HEADERS(unistd.h)'</SAMP>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_USG</B>
+ <DD><A NAME="IDX990"></A>
+ <A NAME="IDX991"></A>
+ <A NAME="IDX992"></A>
+ 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 See section <A HREF="autoconf.html#SEC37">Standard Symbols</A>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_UTIME_NULL</B>
+ <DD><A NAME="IDX993"></A>
+ <A NAME="IDX994"></A>
+ <CODE>AC_FUNC_UTIME_NULL</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_VALIDATE_CACHED_SYSTEM_TUPLE</B> <I>(@ovar{cmd})</I>
+ <DD><A NAME="IDX995"></A>
+ <A NAME="IDX996"></A>
+ 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.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_VERBOSE</B> <I>(<VAR>result-description</VAR>)</I>
+ <DD><A NAME="IDX997"></A>
+ <A NAME="IDX998"></A>
+ <CODE>AC_MSG_RESULT</CODE>.
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_VFORK</B>
+ <DD><A NAME="IDX999"></A>
+ <A NAME="IDX1000"></A>
+ <CODE>AC_FUNC_VFORK</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_VPRINTF</B>
+ <DD><A NAME="IDX1001"></A>
+ <A NAME="IDX1002"></A>
+ <CODE>AC_FUNC_VPRINTF</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_WAIT3</B>
+ <DD><A NAME="IDX1003"></A>
+ <A NAME="IDX1004"></A>
+ <CODE>AC_FUNC_WAIT3</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_WARN</B>
+ <DD><A NAME="IDX1005"></A>
+ <A NAME="IDX1006"></A>
+ <CODE>AC_MSG_WARN</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_WORDS_BIGENDIAN</B>
+ <DD><A NAME="IDX1007"></A>
+ <A NAME="IDX1008"></A>
+ <CODE>AC_C_BIGENDIAN</CODE>
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_XENIX_DIR</B>
+ <DD><A NAME="IDX1009"></A>
+ <A NAME="IDX1010"></A>
+ <A NAME="IDX1011"></A>
+ This macro used to add @option{-lx} to output variable <CODE>LIBS</CODE> if on
+ Xenix. Also, if <TT>`dirent.h'</TT> is being checked for, added
+ @option{-ldir} 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:
+
+
+ <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>
+
+ </DL>
+
+ <DL>
+ <DT><U>Macro:</U> <B>AC_YYTEXT_POINTER</B>
+ <DD><A NAME="IDX1012"></A>
+ <A NAME="IDX1013"></A>
+ <CODE>AC_DECL_YYTEXT</CODE>
+ </DL>
+
+
+
+ <H2><A NAME="SEC151" HREF="autoconf_toc.html#TOC151">Upgrading From Version 1</A></H2>
+
+ <P>
+ Autoconf version 2 is mostly backward compatible with version 1.
+ However, it introduces better ways to do some things, and doesn't
+ support some of the ugly things in version 1. So, depending on how
+ sophisticated your <TT>`configure.ac'</TT> files are, you might have to do
+ some manual work in order to upgrade to version 2. This chapter points
+ out some problems to watch for when upgrading. Also, perhaps your
+ @command{configure} scripts could benefit from some of the new features in
+ version 2; the changes are summarized in the file <TT>`NEWS'</TT> in the
+ Autoconf distribution.
+
+
+
+
+ <H3><A NAME="SEC152" HREF="autoconf_toc.html#TOC152">Changed File Names</A></H3>
+
+ <P>
+ If you have an <TT>`aclocal.m4'</TT> installed with Autoconf (as opposed to
+ in a particular package's source directory), you must rename it to
+ <TT>`acsite.m4'</TT>. See section <A HREF="autoconf.html#SEC13">Using @command{autoconf} to Create @command{configure}</A>.
+
+
+ <P>
+ If you distribute <TT>`install.sh'</TT> with your package, rename it to
+ <TT>`install-sh'</TT> so <CODE>make</CODE> builtin rules won't inadvertently
+ create a file called <TT>`install'</TT> from it. <CODE>AC_PROG_INSTALL</CODE>
+ looks for the script under both names, but it is best to use the new name.
+
+
+ <P>
+ If you were using <TT>`config.h.top'</TT>, <TT>`config.h.bot'</TT>, or
+ <TT>`acconfig.h'</TT>, you still can, but you will have less clutter if you
+ use the <CODE>AH_</CODE> macros. See section <A HREF="autoconf.html#SEC30">Autoheader Macros</A>.
+
+
+
+
+ <H3><A NAME="SEC153" HREF="autoconf_toc.html#TOC153">Changed Makefiles</A></H3>
+
+ <P>
+ Add <SAMP>`@CFLAGS@'</SAMP>, <SAMP>`@CPPFLAGS@'</SAMP>, and <SAMP>`@LDFLAGS@'</SAMP> in
+ your <TT>`Makefile.in'</TT> files, so they can take advantage of the values
+ of those variables in the environment when @command{configure} is run.
+ Doing this isn't necessary, but it's a convenience for users.
+
+
+ <P>
+ Also add <SAMP>`@configure_input@'</SAMP> in a comment to each input file for
+ <CODE>AC_OUTPUT</CODE>, so that the output files will contain a comment saying
+ they were produced by @command{configure}. Automatically selecting the
+ right comment syntax for all the kinds of files that people call
+ <CODE>AC_OUTPUT</CODE> on became too much work.
+
+
+ <P>
+ Add <TT>`config.log'</TT> and <TT>`config.cache'</TT> to the list of files you
+ remove in <CODE>distclean</CODE> targets.
+
+
+ <P>
+ If you have the following in <TT>`Makefile.in'</TT>:
+
+
+
+ <PRE>
+ prefix = /usr/local
+ exec_prefix = $(prefix)
+ </PRE>
+
+ <P>
+ you must change it to:
+
+
+
+ <PRE>
+ prefix = @prefix@
+ exec_prefix = @exec_prefix@
+ </PRE>
+
+ <P>
+ The old behavior of replacing those variables without <SAMP>`@'</SAMP>
+ characters around them has been removed.
+
+
+
+
+ <H3><A NAME="SEC154" HREF="autoconf_toc.html#TOC154">Changed Macros</A></H3>
+
+ <P>
+ Many of the macros were renamed in Autoconf version 2. You can still
+ use the old names, but the new ones are clearer, and it's easier to find
+ the documentation for them. See section <A HREF="autoconf.html#SEC150">Obsolete Macros</A>, for a table showing the
+ new names for the old macros. Use the @command{autoupdate} program to
+ convert your <TT>`configure.ac'</TT> to using the new macro names.
+ See section <A HREF="autoconf.html#SEC149">Using @command{autoupdate} to Modernize @file{configure.ac}</A>.
+
+
+ <P>
+ Some macros have been superseded by similar ones that do the job better,
+ but are not call-compatible. If you get warnings about calling obsolete
+ macros while running @command{autoconf}, you may safely ignore them, but
+ your @command{configure} script will generally work better if you follow
+ the advice it prints about what to replace the obsolete macros with. In
+ particular, the mechanism for reporting the results of tests has
+ changed. If you were using <CODE>echo</CODE> or <CODE>AC_VERBOSE</CODE> (perhaps
+ via <CODE>AC_COMPILE_CHECK</CODE>), your @command{configure} script's output will
+ look better if you switch to <CODE>AC_MSG_CHECKING</CODE> and
+ <CODE>AC_MSG_RESULT</CODE>. See section <A HREF="autoconf.html#SEC86">Printing Messages</A>. Those macros work best
+ in conjunction with cache variables. See section <A HREF="autoconf.html#SEC82">Caching Results</A>.
+
+
+
+
+ <H3><A NAME="SEC155" HREF="autoconf_toc.html#TOC155">Changed Results</A></H3>
+
+ <P>
+ If you were checking the results of previous tests by examining the
+ shell variable <CODE>DEFS</CODE>, you need to switch to checking the values of
+ the cache variables for those tests. <CODE>DEFS</CODE> no longer exists while
+ @command{configure} is running; it is only created when generating output
+ files. This difference from version 1 is because properly quoting the
+ contents of that variable turned out to be too cumbersome and
+ inefficient to do every time <CODE>AC_DEFINE</CODE> is called. See section <A HREF="autoconf.html#SEC83">Cache Variable Names</A>.
+
+
+ <P>
+ For example, here is a <TT>`configure.ac'</TT> fragment written for Autoconf
+ version 1:
+
+
+
+ <PRE>
+ AC_HAVE_FUNCS(syslog)
+ case "$DEFS" in
+ *-DHAVE_SYSLOG*) ;;
+ *) # syslog is not in the default libraries. See if it's in some other.
+ saved_LIBS="$LIBS"
+ for lib in bsd socket inet; do
+ AC_CHECKING(for syslog in -l$lib)
+ LIBS="$saved_LIBS -l$lib"
+ AC_HAVE_FUNCS(syslog)
+ case "$DEFS" in
+ *-DHAVE_SYSLOG*) break ;;
+ *) ;;
+ esac
+ LIBS="$saved_LIBS"
+ done ;;
+ esac
+ </PRE>
+
+ <P>
+ Here is a way to write it for version 2:
+
+
+
+ <PRE>
+ AC_CHECK_FUNCS(syslog)
+ if test $ac_cv_func_syslog = no; then
+ # syslog is not in the default libraries. See if it's in some other.
+ for lib in bsd socket inet; do
+ AC_CHECK_LIB($lib, syslog, [AC_DEFINE(HAVE_SYSLOG)
+ LIBS="$LIBS -l$lib"; break])
+ done
+ fi
+ </PRE>
+
+ <P>
+ If you were working around bugs in <CODE>AC_DEFINE_UNQUOTED</CODE> by adding
+ backslashes before quotes, you need to remove them. It now works
+ predictably, and does not treat quotes (except back quotes) specially.
+ See section <A HREF="autoconf.html#SEC81">Setting Output Variables</A>.
+
+
+ <P>
+ All of the boolean shell variables set by Autoconf macros now use
+ <SAMP>`yes'</SAMP> for the true value. Most of them use <SAMP>`no'</SAMP> for false,
+ though for backward compatibility some use the empty string instead. If
+ you were relying on a shell variable being set to something like 1 or
+ <SAMP>`t'</SAMP> for true, you need to change your tests.
+
+
+
+
+ <H3><A NAME="SEC156" HREF="autoconf_toc.html#TOC156">Changed Macro Writing</A></H3>
+
+ <P>
+ When defining your own macros, you should now use <CODE>AC_DEFUN</CODE>
+ instead of <CODE>define</CODE>. <CODE>AC_DEFUN</CODE> automatically calls
+ <CODE>AC_PROVIDE</CODE> and ensures that macros called via <CODE>AC_REQUIRE</CODE>
+ do not interrupt other macros, to prevent nested <SAMP>`checking...'</SAMP>
+ messages on the screen. There's no actual harm in continuing to use the
+ older way, but it's less convenient and attractive. See section <A HREF="autoconf.html#SEC102">Macro Definitions</A>.
+
+
+ <P>
+ You probably looked at the macros that came with Autoconf as a guide for
+ how to do things. It would be a good idea to take a look at the new
+ versions of them, as the style is somewhat improved and they take
+ advantage of some new features.
+
+
+ <P>
+ If you were doing tricky things with undocumented Autoconf internals
+ (macros, variables, diversions), check whether you need to change
+ anything to account for changes that have been made. Perhaps you can
+ even use an officially supported technique in version 2 instead of
+ kludging. Or perhaps not.
+
+
+ <P>
+ To speed up your locally written feature tests, add caching to them.
+ See whether any of your tests are of general enough usefulness to
+ encapsulate into macros that you can share.
+
+
+
+
+ <H2><A NAME="SEC157" HREF="autoconf_toc.html#TOC157">Upgrading From Version 2.13</A></H2>
+
+ <P>
+ The introduction of the previous section (see section <A HREF="autoconf.html#SEC151">Upgrading From Version 1</A>) perfectly
+ suits this section...
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ Autoconf version 2.50 is mostly backward compatible with version 2.13.
+ However, it introduces better ways to do some things, and doesn't
+ support some of the ugly things in version 2.13. So, depending on how
+ sophisticated your <TT>`configure.ac'</TT> files are, you might have to do
+ some manual work in order to upgrade to version 2.50. This chapter
+ points out some problems to watch for when upgrading. Also, perhaps
+ your @command{configure} scripts could benefit from some of the new
+ features in version 2.50; the changes are summarized in the file
+ <TT>`NEWS'</TT> in the Autoconf distribution.
+ </BLOCKQUOTE>
+
+
+
+ <H3><A NAME="SEC158" HREF="autoconf_toc.html#TOC158">Changed Quotation</A></H3>
+
+ <P>
+ The most important changes are invisible to you: the implementation of
+ most macros have completely changed. This allowed more factorization of
+ the code, better error messages, a higher uniformity of the user's
+ interface etc. Unfortunately, as a side effect, some construct which
+ used to (miraculously) work might break starting with Autoconf 2.50.
+ The most common culprit is bad quotation.
+
+
+ <P>
+ For instance, in the following example, the message is not properly
+ quoted:
+
+
+
+ <PRE>
+ AC_INIT
+ AC_CHECK_HEADERS(foo.h,,
+ AC_MSG_ERROR(cannot find foo.h, bailing out))
+ AC_OUTPUT
+ </PRE>
+
+ <P>
+ Autoconf 2.13 simply ignores it:
+
+
+
+ <PRE>
+ $ <KBD>autoconf-2.13; ./configure --silent</KBD>
+ creating cache ./config.cache
+ configure: error: cannot find foo.h
+ $
+ </PRE>
+
+ <P>
+ while Autoconf 2.50 will produce a broken <TT>`configure'</TT>:
+
+
+
+ <PRE>
+ $ <KBD>autoconf-2.50; ./configure --silent</KBD>
+ configure: error: cannot find foo.h
+ ./configure: exit: bad non-numeric arg `bailing'
+ ./configure: exit: bad non-numeric arg `bailing'
+ $
+ </PRE>
+
+ <P>
+ The message needs to be quoted, and the <CODE>AC_MSG_ERROR</CODE> invocation
+ too!
+
+
+
+ <PRE>
+ AC_INIT
+ AC_CHECK_HEADERS(foo.h,,
+ [AC_MSG_ERROR([cannot find foo.h, bailing out])])
+ AC_OUTPUT
+ </PRE>
+
+ <P>
+ Many many (and many more) Autoconf macros were lacking proper quotation,
+ including no less than... <CODE>AC_DEFUN</CODE> itself!
+
+
+
+ <PRE>
+ $ <KBD>cat configure.in</KBD>
+ AC_DEFUN([AC_PROG_INSTALL],
+ [# My own much better version
+ ])
+ AC_INIT
+ AC_PROG_INSTALL
+ AC_OUTPUT
+ $ <KBD>autoconf-2.13</KBD>
+ autoconf: Undefined macros:
+ ***BUG in Autoconf--please report*** AC_FD_MSG
+ ***BUG in Autoconf--please report*** AC_EPI
+ configure.in:1:AC_DEFUN([AC_PROG_INSTALL],
+ configure.in:5:AC_PROG_INSTALL
+ $ <KBD>autoconf-2.50</KBD>
+ $
+ </PRE>
+
+
+
+ <H3><A NAME="SEC159" HREF="autoconf_toc.html#TOC159">New Macros</A></H3>
+
+ <P>
+ <A NAME="IDX1014"></A>
+
+
+ <P>
+ Because Autoconf has been dormant for years, Automake provided
+ Autoconf-like macros for a while. Autoconf 2.50 now provides better
+ versions of these macros, integrated in the <CODE>AC_</CODE> namespace,
+ instead of <CODE>AM_</CODE>. But in order to ease the upgrading via
+ @command{autoupdate}, bindings to such <CODE>AM_</CODE> macros are provided.
+
+
+ <P>
+ Unfortunately Automake did not quote the name of these macros!
+ Therefore, when @command{m4} finds something like
+ <SAMP>`AC_DEFUN(AM_TYPE_PTRDIFF_T, ...)'</SAMP> in <TT>`aclocal.m4'</TT>,
+ <CODE>AM_TYPE_PTRDIFF_T</CODE> is
+ expanded, replaced with its Autoconf definition.
+
+
+ <P>
+ Fortunately Autoconf catches pre-<CODE>AC_INIT</CODE> expansions, and will
+ complain, in its own words:
+
+
+
+ <PRE>
+ $ <KBD>cat configure.in</KBD>
+ AC_INIT
+ AM_TYPE_PTRDIFF_T
+ $ <KBD>aclocal-1.4</KBD>
+ $ <KBD>autoconf</KBD>
+ ./aclocal.m4:17: error: m4_defn: undefined macro: _m4_divert_diversion
+ actypes.m4:289: AM_TYPE_PTRDIFF_T is expanded from...
+ ./aclocal.m4:17: the top level
+ $
+ </PRE>
+
+ <P>
+ Future versions of Automake will simply no longer define most of these
+ macros, and will properly quote the names of the remaining macros.
+ But you don't have to wait for it to happen to do the right thing right
+ now: do not depend upon macros from Automake as it is simply not its job
+ to provide macros (but the one it requires by itself):
+
+
+
+ <PRE>
+ $ <KBD>cat configure.in</KBD>
+ AC_INIT
+ AM_TYPE_PTRDIFF_T
+ $ <KBD>rm aclocal.m4</KBD>
+ $ <KBD>autoupdate</KBD>
+ autoupdate: `configure.in' is updated
+ $ <KBD>cat configure.in</KBD>
+ AC_INIT
+ AC_CHECK_TYPES([ptrdiff_t])
+ $ <KBD>aclocal-1.4</KBD>
+ $ <KBD>autoconf</KBD>
+ $
+ </PRE>
+
+
+
+ <H3><A NAME="SEC160" HREF="autoconf_toc.html#TOC160">Hosts and Cross-Compilation</A></H3>
+
+ <P>
+ Based on the experience of compiler writers, and after long public
+ debates, many aspects of the cross-compilation chain have changed:
+
+
+
+ <UL>
+ <LI>
+
+ the relationship between the build, host, and target architecture types,
+
+ <LI>
+
+ the command line interface for specifying them to @command{configure},
+
+ <LI>
+
+ the variables defined in @command{configure},
+
+ <LI>
+
+ the enabling of cross-compilation mode.
+ </UL>
+
+ <P>
+ The relationship between build, host, and target have been cleaned up:
+ the chain of default is now simply: target defaults to host, host to
+ build, and build to the result of @command{config.guess}. Nevertheless,
+ in order to ease the transition from 2.13 to 2.50, the following
+ transition scheme is implemented. <EM>Do not rely on it</EM>, as it will
+ be completely disabled in a couple of releases (we cannot keep it, as it
+ proves to cause more problems than to cure).
+
+
+ <P>
+ They all default to the result of running @command{config.guess}, unless
+ you specify either @option{--build} or @option{--host}. In this case,
+ the default becomes the system type you specified. If you specify both,
+ and they're different, @command{configure} will enter cross compilation
+ mode, so it won't run any tests that require execution.
+
+
+ <P>
+ Hint: if you mean to override the result of @command{config.guess},
+ prefer @option{--build} over @option{--host}. In the future,
+ @option{--host} will not override the name of the build system type.
+ Whenever you specify <CODE>--host</CODE>, be sure to specify <CODE>--build</CODE>
+ too.
+
+
+ <P>
+ For backward compatibility, @command{configure} will accept a system
+ type as an option by itself. Such an option will override the defaults
+ for build, host and target system types. The following configure
+ statement will configure a cross toolchain that will run on NetBSD/alpha
+ but generate code for GNU Hurd/sparc, which is also the build platform.
+
+
+
+ <PRE>
+ ./configure --host=alpha-netbsd sparc-gnu
+ </PRE>
+
+ <P>
+ In Autoconf, the variables <CODE>build</CODE>, <CODE>host</CODE>, and <CODE>target</CODE>
+ had a different semantics before and after the invocation of
+ <CODE>AC_CANONICAL_BUILD</CODE> etc. Now, the argument of @option{--build} is
+ strictly copied into <CODE>build_alias</CODE>, and is left empty otherwise.
+ After the <CODE>AC_CANONICAL_BUILD</CODE>, <CODE>build</CODE> is set to the
+ canonicalized build type. To ease the transition, before, its contents
+ is the same as that of <CODE>build_alias</CODE>. Do <EM>not</EM> rely on this
+ broken feature.
+
+
+ <P>
+ For consistency with the backward compatibility scheme exposed above,
+ when @option{--host} is specified by @option{--build} isn't, the build
+ system will be assumed to be the same as @option{--host}, and
+ <SAMP>`build_alias'</SAMP> will be set to that value. Eventually, this
+ historically incorrect behavior will go away.
+
+
+ <P>
+ The former scheme to enable cross-compilation proved to cause more harm
+ than good, in particular, it used to be triggered too easily, leaving
+ regular end users puzzled in front of cryptic error messages.
+ @command{configure} could even enter cross-compilation mode, only
+ because the compiler was not functional. This is mainly because
+ @command{configure} used to try to detect cross-compilation, instead of
+ waiting for an explicit flag from the user.
+
+
+ <P>
+ Now, @command{configure} enters cross-compilation mode iff
+ @option{--host} is passed.
+
+
+ <P>
+ That's the short documentation. To ease the transition between 2.13 and
+ its successors, a more complicated scheme is implemented. <EM>Do not
+ rely on the following</EM>, as it will be removed in a near future.
+
+
+ <P>
+ If you specify @option{--host}, but not @option{--build}, when
+ @command{configure} performs the first compiler test it will try to run
+ an executable produced by the compiler. If the execution fails, it will
+ enter cross-compilation mode. This is fragile. Moreover, by the time
+ the compiler test is performed, it may be too late to modify the
+ build-system type: other tests may have already been performed.
+ Therefore, whenever you specify <CODE>--host</CODE>, be sure to specify
+ <CODE>--build</CODE> too.
+
+
+
+ <PRE>
+ ./configure --build=i686-pc-linux-gnu --host=m68k-coff
+ </PRE>
+
+ <P>
+ will enter cross-compilation mode. The former interface, which
+ consisted in setting the compiler to a cross-compiler without informing
+ @command{configure} is obsolete. For instance, @command{configure} will
+ fail if it can't run the code generated by the specified compiler if you
+ configure as follows:
+
+
+
+ <PRE>
+ ./configure CC=m68k-coff-gcc
+ </PRE>
+
+
+
+ <H3><A NAME="SEC161" HREF="autoconf_toc.html#TOC161"><CODE>AC_LIBOBJ</CODE> vs. <CODE>LIBOBJS</CODE></A></H3>
+
+ <P>
+ Up to Autoconf 2.13, the replacement of functions was triggered via the
+ variable <CODE>LIBOBJS</CODE>. Since Autoconf 2.50, the macro
+ <CODE>AC_LIBOBJ</CODE> should be used instead (see section <A HREF="autoconf.html#SEC47">Generic Function Checks</A>).
+ Starting at Autoconf 2.53, the use of <CODE>LIBOBJS</CODE> is an error.
+
+
+ <P>
+ This change is mandated by the unification of the GNU Build System
+ components. In particular, the various fragile techniques used to parse
+ a <TT>`configure.ac'</TT> are all replaced with the use of traces. As a
+ consequence, any action must be traceable, which obsoletes critical
+ variable assignments. Fortunately, <CODE>LIBOBJS</CODE> was the only problem.
+
+
+ <P>
+ At the time this documentation is written, Automake does not rely on
+ traces yet, but this is planed for a near future. Nevertheless, to
+ ease the transition, and to guarantee this future Automake release will
+ be able to use Autoconf 2.53, using <CODE>LIBOBJS</CODE> directly will make
+ @command{autoconf} fail. But note that the output, @command{configure},
+ is correct and fully functional: you have some delay to adjust your
+ source.
+
+
+ <P>
+ There are two typical uses of <CODE>LIBOBJS</CODE>: asking for a replacement
+ function, and adjusting <CODE>LIBOBJS</CODE> for Automake and/or Libtool.
+
+
+ <P>
+ As for function replacement, the fix is immediate: use
+ <CODE>AC_LIBOBJ</CODE>. For instance:
+
+
+
+ <PRE>
+ LIBOBJS="$LIBOBJS fnmatch.o"
+ LIBOBJS="$LIBOBJS malloc.$ac_objext"
+ </PRE>
+
+ <P>
+ should be replaced with:
+
+
+
+ <PRE>
+ AC_LIBOBJ([fnmatch])
+ AC_LIBOBJ([malloc])
+ </PRE>
+
+ <P>
+ When asked for automatic de-ANSI-fication, Automake needs
+ <CODE>LIBOBJS</CODE>'ed filenames to have <SAMP>`$U'</SAMP> appended to the
+ base names. Libtool requires the definition of <CODE>LTLIBOBJS</CODE>, which
+ suffixes are mapped to <SAMP>`.lo'</SAMP>. Although Autoconf provides them with
+ means to free the user to do that by herself, by the time of this
+ writing, none do. Therefore, it is common to see <TT>`configure.ac'</TT>
+ end with:
+
+
+
+ <PRE>
+ # This is necessary so that .o files in LIBOBJS are also built via
+ # the ANSI2KNR-filtering rules.
+ LIBOBJS=`echo "$LIBOBJS" | sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`
+ LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.o/\.lo/g'`
+ AC_SUBST(LTLIBOBJS)
+ </PRE>
+
+ <P>
+ First, note that this code is <EM>wrong</EM>, because <SAMP>`.o'</SAMP> is not the
+ only possible extension<A NAME="DOCF4" HREF="autoconf_foot.html#FOOT4">(4)</A>! Because the token <CODE>LIBOBJS</CODE> is now
+ forbidden, you will have to replace this snippet with:
+
+
+
+ <PRE>
+ # This is necessary so that .o files in LIBOBJS are also built via
+ # the ANSI2KNR-filtering rules.
+ LIB@&t@OBJS=`echo "$LIB@&t@OBJS" |
+ sed 's,\.[[^.]]* ,$U&,g;s,\.[[^.]]*$,$U&,'`
+ LTLIBOBJS=`echo "$LIB@&t@OBJS" |
+ sed 's,\.[[^.]]* ,.lo ,g;s,\.[[^.]]*$,.lo,'`
+ AC_SUBST(LTLIBOBJS)
+ </PRE>
+
+ <P>
+ Unfortunately, @command{autoupdate} cannot help here, since... this is
+ not a macro! Of course, first make sure your release of Automake and/or
+ Libtool still requires these.
+
+
+
+
+ <H1><A NAME="SEC162" HREF="autoconf_toc.html#TOC162">Generating Test Suites with Autotest</A></H1>
+
+ <P>
+ <A NAME="IDX1015"></A>
+
+
+
+ <PRE>
+ <STRONG>Note: This section describes an experimental feature which will
+ be part of Autoconf in a forthcoming release. Although we believe
+ Autotest is stabilizing, this documentation describes an interface which
+ might change in the future: do not depend upon Autotest without
+ subscribing to the Autoconf mailing lists.</STRONG>
+ </PRE>
+
+ <P>
+ It is paradoxical that portable projects depend on nonportable tools to
+ run their test suite. Autoconf by itself is the paragon of this
+ problem: although it aims at perfectly portability, up to 2.13, its test
+ suite was using DejaGNU, a rich and complex testing framework, but which
+ is far from being standard on Unix systems. Worse yet, it was likely to
+ be missing on the most fragile platforms, the very platforms that are
+ most likely to torture Autoconf and exhibit deficiencies.
+
+
+ <P>
+ To circumvent this problem many package maintainers have developed their
+ own testing framework, based on simple shell scripts whose sole output
+ are their exit status: the test succeeded, or failed. In addition, most
+ of these tests share some common patterns, what results in lots of
+ duplicated code, tedious maintenance etc.
+
+
+ <P>
+ Following exactly the same reasoning that yielded to the inception of
+ Autoconf, Autotest provides a test suite generation frame work, based on
+ M4 macros, building a portable shell script. The suite itself is
+ equipped with automatic logging and tracing facilities which greatly
+ diminish the interaction with bug reporters, and simple timing reports.
+
+
+ <P>
+ Autoconf itself has been using Autotest for years, and we do attest that
+ it has considerably improved the strength of the test suite, and the
+ quality of bug reports. Other projects are known to use some generation
+ of Autotest, such as Bison, Free Recode, Free Wdiff, GNU Tar, each of
+ them having different needs, what slowly polishes Autotest as a general
+ testing framework.
+
+
+ <P>
+ Nonetheless, compared to DejaGNU, Autotest is inadequate for interactive
+ tool testing, which is probably its main limitation.
+
+
+
+
+ <H2><A NAME="SEC163" HREF="autoconf_toc.html#TOC163">Using an Autotest Test Suite</A></H2>
+
+
+
+ <H3><A NAME="SEC164" HREF="autoconf_toc.html#TOC164">@command{testsuite} Scripts</A></H3>
+
+ <P>
+ <A NAME="IDX1016"></A>
+
+
+ <P>
+ Generating testing or validation suites using Autotest is rather easy.
+ The whole validation suite is held in a file to be processed through
+ @command{autom4te}, itself using GNU <CODE>m4</CODE> under the scene, to
+ produce a stand-alone Bourne shell script which then gets distributed.
+ Neither @command{autom4te} nor GNU <CODE>m4</CODE> are not needed anymore at
+ the installer end.
+
+
+ <P>
+ <A NAME="IDX1017"></A>
+ Each test of the validation suite should be part of some test group. A
+ <EM>test group</EM> is a sequence of interwoven tests that ought to be
+ executed together, usually because one test in the group creates data
+ files than a later test in the same group needs to read. Complex test
+ groups make later debugging more tedious. It is much better keeping
+ keep only a few tests per test group, and if you can put only one test
+ per test group, this is just ideal.
+
+
+ <P>
+ For all but the simplest packages, some file such as <TT>`testsuite.at'</TT>
+ does not fully hold all test sources, as these are often easier to
+ maintain in separate files. Each of these separate files holds a single
+ test group, or a sequence of test groups all addressing some common
+ functionality in the package. In such cases, file <TT>`testsuite.at'</TT>
+ only initializes the whole validation suite, and sometimes do elementary
+ health checking, before listing include statements for all other test
+ files. The special file <TT>`package.m4'</TT>, containing the
+ identification of the package, is automatically included if found.
+
+
+ <P>
+ The validation scripts that Autotest produces are by convention called
+ @command{testsuite}. When run, @command{testsuite} executes each test
+ group in turn, producing only one summary line per test to say if that
+ particular test succeeded or failed. At end of all tests, summarizing
+ counters get printed. If any test failed, one debugging script gets
+ automatically generated for each test group which failed. These
+ debugging scripts are named <TT>`testsuite.<VAR>nn</VAR>'</TT>, where <VAR>nn</VAR> is
+ the sequence number of the test group. In the ideal situation, none of
+ the tests fail, and consequently, no debugging script is generated out
+ of validation.
+
+
+ <P>
+ The automatic generation of debugging scripts for failed test has the
+ purpose of easing the chase for bugs.
+
+
+ <P>
+ It often happens in practice that individual tests in the validation
+ suite need to get information coming out of the configuration process.
+ Some of this information, common for all validation suites, is provided
+ through the file <TT>`atconfig'</TT>, automatically created by
+ <CODE>AC_CONFIG_TESTDIR</CODE>. For configuration informations which your
+ testing environment specifically needs, you might prepare an optional
+ file named <TT>`atlocal.in'</TT>, instantiated by <CODE>AC_CONFIG_FILES</CODE>.
+ The configuration process produces <TT>`atconfig'</TT> and <TT>`atlocal'</TT>
+ out of these two input files, and these two produced files are
+ automatically read by the <TT>`testsuite'</TT> script.
+
+
+ <P>
+ Here is a diagram showing the relationship between files.
+
+
+ <P>
+ Files used in preparing a software package for distribution:
+
+
+
+ <PRE>
+ subfile-1.at ->.
+ ... \
+ subfile-i.at ---->-- testsuite.at -->.
+ ... / \
+ subfile-n.at ->' >-- autom4te* -->testsuite
+ /
+ [package.m4] ->'
+ </PRE>
+
+ <P>
+ Files used in configuring a software package:
+
+
+
+ <PRE>
+ .--> atconfig
+ /
+ [atlocal.in] --> config.status* --<
+ \
+ `--> [atlocal]
+ </PRE>
+
+ <P>
+ Files created during the test suite execution:
+
+
+
+ <PRE>
+ atconfig -->. .--> testsuite.log
+ \ /
+ >-- testsuite* --<
+ / \
+ [atlocal] ->' `--> [testsuite.<VAR>nn</VAR>*]
+ </PRE>
+
+
+
+ <H3><A NAME="SEC165" HREF="autoconf_toc.html#TOC165">Autotest Logs</A></H3>
+
+ <P>
+ When run, the test suite creates a log file named after itself, e.g., a
+ test suite named @command{testsuite} creates <TT>`testsuite.log'</TT>. It
+ contains a lot of information, usually more than maintainers actually
+ need, but therefore most of the time it contains all that is needed:
+
+
+ <DL COMPACT>
+
+ <DT>command line arguments
+ <DD>
+ A very bad Unix habit which is unfortunately wide spread consists of
+ setting environment variables before the command, such as in
+ <SAMP>`CC=my-home-grown-cc ./testsuite'</SAMP>. This results in the test suite
+ not knowing this change, hence (i) it can't report it to you, and (ii)
+ it cannot preserve the value of <CODE>CC</CODE> for subsequent runs<A NAME="DOCF5" HREF="autoconf_foot.html#FOOT5">(5)</A>. Autoconf faced exactly the same problem, and solved it by asking
+ users to pass the variable definitions as command line arguments.
+ Autotest requires this rule too, but has no means to enforce it; the log
+ then contains a trace of the variables the user changed.
+
+ <DT><TT>`ChangeLog'</TT> excerpts
+ <DD>
+ The topmost lines of all the <TT>`ChangeLog'</TT>s found in the source
+ hierarchy. This is especially useful when bugs are reported against
+ development versions of the package, since the version string does not
+ provide sufficient information to know the exact state of the sources
+ the user compiled. Of course this relies on the use of a
+ <TT>`ChangeLog'</TT>.
+
+ <DT>build machine
+ <DD>
+ Running a test suite in a cross-compile environment is not an easy task,
+ since it would mean having the test suite run on a machine <VAR>build</VAR>,
+ while running programs on a machine <VAR>host</VAR>. It is much simpler to
+ run both the test suite and the programs on <VAR>host</VAR>, but then, from
+ the point of view of the test suite, there remains a single environment,
+ <VAR>host</VAR> = <VAR>build</VAR>. The log contains relevant information on the
+ state of the build machine, including some important environment
+ variables.
+
+ <DT>tested programs
+ <DD>
+ The absolute path and answers to @option{--version} of the tested
+ programs (see section <A HREF="autoconf.html#SEC166">Writing <TT>`testsuite.at'</TT></A>, <CODE>AT_TESTED</CODE>).
+
+ <DT>configuration log
+ <DD>
+ The contents of <TT>`config.log'</TT>, as created by @command{configure},
+ are appended. It contains the configuration flags and a detailed report
+ on the configuration itself.
+ </DL>
+
+
+
+ <H2><A NAME="SEC166" HREF="autoconf_toc.html#TOC166">Writing <TT>`testsuite.at'</TT></A></H2>
+
+ <P>
+ The <TT>`testsuite.at'</TT> is a Bourne shell script making use of special
+ Autotest M4 macros. It often contains a call to <CODE>AT_INIT</CODE> nears
+ its beginning followed by one call to <CODE>m4_include</CODE> per source file
+ for tests. Each such included file, or the remainder of
+ <TT>`testsuite.at'</TT> if include files are not used, contain a sequence of
+ test groups. Each test group begins with one call to <CODE>AT_SETUP</CODE>,
+ it contains an arbitrary number of shell commands or calls to
+ <CODE>AT_CHECK</CODE>, and it completes with one call to <CODE>AT_CLEANUP</CODE>.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AT_INIT</B> <I>(@ovar{name})</I>
+ <DD><A NAME="IDX1018"></A>
+ <A NAME="IDX1019"></A>
+ Initialize Autotest. Giving a <VAR>name</VAR> to the test suite is
+ encouraged if your package includes several test suites. In any case,
+ the test suite always displays the package name and version. It also
+ inherits the package bug report address.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AT_TESTED</B> <I>(<VAR>executables</VAR>)</I>
+ <DD><A NAME="IDX1020"></A>
+ <A NAME="IDX1021"></A>
+ Log the path and answer to @option{--version} 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.
+ </DL>
+
+
+ <P>
+ Autotest test suites rely on the <CODE>PATH</CODE> to find the tested program.
+ This saves from generating the absolute paths to the various tools, and
+ makes it possible to test installed programs. Therefore, knowing what
+ programs are being exercised is crucial to understand some problems in
+ the test suite itself, or its occasional misuses. It is a good idea to
+ also subscribe foreign programs you depend upon, to ease incompatibility
+ diagnostics.
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AT_SETUP</B> <I>(<VAR>test-group-name</VAR>)</I>
+ <DD><A NAME="IDX1022"></A>
+ <A NAME="IDX1023"></A>
+ 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.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AT_KEYWORDS</B> <I>(<VAR>keywords</VAR>)</I>
+ <DD><A NAME="IDX1024"></A>
+ <A NAME="IDX1025"></A>
+ 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>title</VAR> of the test group is automatically recorded to
+ <CODE>AT_KEYWORDS</CODE>.
+
+
+ <P>
+ Several invocations within a test group accumulate new keywords. In
+ other words, don't fear registering several times the same keyword in a
+ test group.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AT_CLEANUP</B>
+ <DD><A NAME="IDX1026"></A>
+ <A NAME="IDX1027"></A>
+ End the current test group.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AT_DATA</B> <I>(<VAR>file</VAR>, <VAR>contents</VAR>)</I>
+ <DD><A NAME="IDX1028"></A>
+ <A NAME="IDX1029"></A>
+ 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 <CODE>m4</CODE>
+ expansion. The contents ought to end with an end of line.
+ </DL>
+
+
+ <P>
+ <DL>
+ <DT><U>Macro:</U> <B>AT_CHECK</B> <I>(<VAR>commands</VAR>, @dvar{status, <SAMP>`0'</SAMP>}, @ovar{stdout}, @ovar{stderr})</I>
+ <DD><A NAME="IDX1030"></A>
+ <A NAME="IDX1031"></A>
+ Execute a test by performing given shell <VAR>commands</VAR>. 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
+ status 77, then the whole test group is skipped.
+
+
+ <P>
+ The <VAR>commands</VAR> <EM>must not</EM> redirect the standard output, nor the
+ standard error.
+
+
+ <P>
+ If <VAR>status</VAR>, or <VAR>stdout</VAR>, or <VAR>stderr</VAR> is <SAMP>`ignore'</SAMP>, then
+ the corresponding value is not checked.
+
+
+ <P>
+ The special value <SAMP>`expout'</SAMP> for <VAR>stdout</VAR> means the expected
+ output of the <VAR>commands</VAR> is the content of the file <TT>`expout'</TT>.
+ If <VAR>stdout</VAR> is <SAMP>`stdout'</SAMP>, then the standard output of the
+ <VAR>commands</VAR> is available for further tests in the file <TT>`stdout'</TT>.
+ Similarly for <VAR>stderr</VAR> with <SAMP>`expout'</SAMP> and <SAMP>`stderr'</SAMP>.
+ </DL>
+
+
+
+
+ <H2><A NAME="SEC167" HREF="autoconf_toc.html#TOC167">Running @command{testsuite} Scripts</A></H2>
+ <P>
+ <A NAME="IDX1032"></A>
+
+
+ <P>
+ Autotest test suites support the following arguments:
+
+
+ <DL COMPACT>
+
+ <DT><SAMP>`--help'</SAMP>
+ <DD>
+ <DT><SAMP>`-h'</SAMP>
+ <DD>
+ Display the list of options and exit successfully.
+
+ <DT><SAMP>`--version'</SAMP>
+ <DD>
+ <DT><SAMP>`-V'</SAMP>
+ <DD>
+ Display the version of the test suite and exit successfully.
+
+ <DT><SAMP>`--clean'</SAMP>
+ <DD>
+ <DT><SAMP>`-c'</SAMP>
+ <DD>
+ Remove all the files the test suite might have created and exit. Meant
+ for <CODE>clean</CODE> Makefile targets.
+
+ <DT><SAMP>`--list'</SAMP>
+ <DD>
+ <DT><SAMP>`-l'</SAMP>
+ <DD>
+ List all the tests (or only the selection), including their possible
+ keywords.
+ </DL>
+
+ <P>
+ By default all the tests are performed (or described with
+ @option{--list}) in the default environment first silently, then
+ verbosely, but the environment, set of tests, and verbosity level can be
+ tuned:
+
+
+ <DL COMPACT>
+
+ <DT><SAMP>`<VAR>variable</VAR>=<VAR>value</VAR>'</SAMP>
+ <DD>
+ Set the environment <VAR>variable</VAR> to <VAR>value</VAR>. Do not run
+ <SAMP>`FOO=foo ./testsuite'</SAMP> as debugging scripts would then run in a
+ different environment.
+
+ <A NAME="IDX1033"></A>
+ The variable <CODE>AUTOTEST_PATH</CODE> specifies the testing path to prepend
+ to <CODE>PATH</CODE>. It handles specially relative paths (not starting with
+ <SAMP>`/'</SAMP>): they are considered to be relative to the top level of the
+ package being built. All the directories are made absolute, first
+ starting from the top level <EM>build</EM> tree, then from the
+ <EM>source</EM> tree. For instance <SAMP>`./testsuite
+ AUTOTEST_PATH=tests:bin'</SAMP> for a <TT>`/src/foo-1.0'</TT> source package built
+ in <TT>`/tmp/foo'</TT> results in <SAMP>`/tmp/foo/tests:/tmp/foo/bin'</SAMP> and
+ then <SAMP>`/src/foo-1.0/tests:/src/foo-1.0/bin'</SAMP> being prepended to
+ <CODE>PATH</CODE>.
+
+ <DT><SAMP>`<VAR>number</VAR>'</SAMP>
+ <DD>
+ <DT><SAMP>`<VAR>number</VAR>-<VAR>number</VAR>'</SAMP>
+ <DD>
+ <DT><SAMP>`<VAR>number</VAR>-'</SAMP>
+ <DD>
+ <DT><SAMP>`-<VAR>number</VAR>'</SAMP>
+ <DD>
+ Add the corresponding test groups, with obvious semantics, to the
+ selection.
+
+ <DT><SAMP>`--keywords=<VAR>keywords</VAR>'</SAMP>
+ <DD>
+ <DT><SAMP>`-k <VAR>keywords</VAR>'</SAMP>
+ <DD>
+ Add to the selection the test groups which title or keywords (arguments
+ to <CODE>AT_SETUP</CODE> or <CODE>AT_KEYWORDS</CODE>) match <EM>all</EM> the keywords
+ of the comma separated list <VAR>keywords</VAR>.
+
+ Running <SAMP>`./testsuite -k autoupdate,FUNC'</SAMP> will select all the tests
+ tagged with <SAMP>`autoupdate'</SAMP> <EM>and</EM> <SAMP>`FUNC'</SAMP> (as in
+ <SAMP>`AC_CHECK_FUNC'</SAMP>, <SAMP>`AC_FUNC_FNMATCH'</SAMP> etc.) while
+ <SAMP>`./testsuite -k autoupdate -k FUNC'</SAMP> runs all the tests tagged with
+ <SAMP>`autoupdate'</SAMP> <EM>or</EM> <SAMP>`FUNC'</SAMP>.
+
+ <DT><SAMP>`--errexit'</SAMP>
+ <DD>
+ <DT><SAMP>`-e'</SAMP>
+ <DD>
+ If any test fails, immediately abort testing. It implies
+ @option{--debug}: post test group clean up, debugging script generation,
+ and logging are inhibited. This option is meant for the full test
+ suite, it is not really useful for generated debugging scripts.
+
+ <DT><SAMP>`--verbose'</SAMP>
+ <DD>
+ <DT><SAMP>`-v'</SAMP>
+ <DD>
+ Force more verbosity in the detailed output of what is being done. This
+ is the default for debugging scripts.
+
+ <DT><SAMP>`--debug'</SAMP>
+ <DD>
+ <DT><SAMP>`-d'</SAMP>
+ <DD>
+ Do not remove the files after a test group was performed --but they are
+ still removed <EM>before</EM>, therefore using this option is sane when
+ running several test groups. Do not create debugging scripts. Do not
+ log (in order to preserve supposedly existing full log file). This is
+ the default for debugging scripts.
+
+ <DT><SAMP>`--trace'</SAMP>
+ <DD>
+ <DT><SAMP>`-x'</SAMP>
+ <DD>
+ Trigger shell tracing of the test groups.
+ </DL>
+
+
+
+ <H2><A NAME="SEC168" HREF="autoconf_toc.html#TOC168">Making @command{testsuite} Scripts</A></H2>
+
+ <P>
+ For putting Autotest into movement, you need some configuration and
+ Makefile machinery. We recommend, at least if your package uses deep or
+ shallow hierarchies, that you use <TT>`tests/'</TT> as the name of the
+ directory holding all your tests and their <TT>`Makefile'</TT>. Here is a
+ check list of things to do.
+
+
+
+ <UL>
+
+ <LI>
+
+ <A NAME="IDX1034"></A>
+ Make sure to create the file <TT>`package.m4'</TT>, which defines the
+ identity of the package. It must define <CODE>AT_PACKAGE_STRING</CODE>, the
+ full signature of the package, and <CODE>AT_PACKAGE_BUGREPORT</CODE>, the
+ address to which bug reports should be sent. For sake of completeness,
+ we suggest that you also define <CODE>AT_PACKAGE_NAME</CODE>,
+ <CODE>AT_PACKAGE_TARNAME</CODE>, and <CODE>AT_PACKAGE_VERSION</CODE>.
+ See section <A HREF="autoconf.html#SEC16">Initializing @command{configure}</A>, for a description of these variables. We
+ suggest the following Makefile excerpt:
+
+
+ <PRE>
+ $(srcdir)/package.m4: $(top_srcdir)/configure.ac
+ { \
+ echo '# Signature of the current package.'; \
+ echo 'm4_define([AT_PACKAGE_NAME], [@PACKAGE_NAME@])'; \
+ echo 'm4_define([AT_PACKAGE_TARNAME], [@PACKAGE_TARNAME@])'; \
+ echo 'm4_define([AT_PACKAGE_VERSION], [@PACKAGE_VERSION@])'; \
+ echo 'm4_define([AT_PACKAGE_STRING], [@PACKAGE_STRING@])'; \
+ echo 'm4_define([AT_PACKAGE_BUGREPORT], [@PACKAGE_BUGREPORT@])'; \
+ } >$(srcdir)/package.m4
+ </PRE>
+
+ Be sure to distribute <TT>`package.m4'</TT> and to put it into the source
+ hierarchy: the test suite ought to be shipped!
+
+ <LI>
+
+ Use the <CODE>AT_CONFIG</CODE> macro from within file <TT>`configure.ac'</TT>.
+ This macro accepts one argument, which is the directory, relative to the
+ test directory, where the executables are prepared.
+
+ <LI>
+
+ Still within <TT>`configure.ac'</TT>, ensure that some
+ <CODE>AC_CONFIG_FILES</CODE> command includes substitution for
+ <TT>`tests/atconfig'</TT> and also, as appropriate, <TT>`tests/atlocal'</TT>.
+
+ <LI>
+
+ The <TT>`tests/Makefile.in'</TT> should be modified so the validation in
+ your package is triggered by <SAMP>`make check'</SAMP>. An example is provided
+ below.
+
+ </UL>
+
+ <P>
+ With Automake, here is a minimal example about how to link <SAMP>`make
+ check'</SAMP> with a validation suite.
+
+
+
+ <PRE>
+ EXTRA_DIST = testsuite.at testsuite
+ TESTSUITE = $(srcdir)/testsuite
+ check-local: atconfig atlocal $(TESTSUITE)
+ $(SHELL) $(TESTSUITE)
+
+ AUTOTEST = $(AUTOM4TE) --language=autotest
+ $(TESTSUITE): $(srcdir)/testsuite.at
+ $(AUTOTEST) -I $(srcdir) $.at -o $.tmp
+ mv $.tmp $
+ </PRE>
+
+ <P>
+ You might want to list explicitly the dependencies, i.e., the list of
+ the files <TT>`testsuite.at'</TT> includes.
+
+
+ <P>
+ With strict Autoconf, you might need to add lines inspired from the
+ following:
+
+
+
+ <PRE>
+ subdir = tests
+
+ atconfig: $(top_builddir)/config.status
+ cd $(top_builddir) && \
+ $(SHELL) ./config.status $(subdir)/$
+
+ atlocal: $(srcdir)/atlocal.in $(top_builddir)/config.status
+ cd $(top_builddir) && \
+ $(SHELL) ./config.status $(subdir)/$
+ </PRE>
+
+ <P>
+ and manage to have <TT>`atconfig.in'</TT> and <CODE>$(EXTRA_DIST)</CODE>
+ distributed.
+
+
+
+
+ <H1><A NAME="SEC169" HREF="autoconf_toc.html#TOC169">Questions About Autoconf</A></H1>
+
+ <P>
+ Several questions about Autoconf come up occasionally. Here some of them
+ are addressed.
+
+
+
+
+ <H2><A NAME="SEC170" HREF="autoconf_toc.html#TOC170">Distributing @command{configure} Scripts</A></H2>
+
+
+ <PRE>
+ What are the restrictions on distributing @command{configure}
+ scripts that Autoconf generates? How does that affect my
+ programs that use them?
+ </PRE>
+
+ <P>
+ There are no restrictions on how the configuration scripts that Autoconf
+ produces may be distributed or used. In Autoconf version 1, they were
+ covered by the GNU General Public License. We still encourage
+ software authors to distribute their work under terms like those of the
+ GPL, but doing so is not required to use Autoconf.
+
+
+ <P>
+ Of the other files that might be used with @command{configure},
+ <TT>`config.h.in'</TT> is under whatever copyright you use for your
+ <TT>`configure.ac'</TT>. <TT>`config.sub'</TT> and <TT>`config.guess'</TT> have an
+ exception to the GPL when they are used with an Autoconf-generated
+ @command{configure} script, which permits you to distribute them under the
+ same terms as the rest of your package. <TT>`install-sh'</TT> is from the X
+ Consortium and is not copyrighted.
+
+
+
+
+ <H2><A NAME="SEC171" HREF="autoconf_toc.html#TOC171">Why Require GNU M4?</A></H2>
+
+
+ <PRE>
+ Why does Autoconf require GNU M4?
+ </PRE>
+
+ <P>
+ Many M4 implementations have hard-coded limitations on the size and
+ number of macros that Autoconf exceeds. They also lack several
+ builtin macros that it would be difficult to get along without in a
+ sophisticated application like Autoconf, including:
+
+
+
+ <PRE>
+ m4_builtin
+ m4_indir
+ m4_bpatsubst
+ __file__
+ __line__
+ </PRE>
+
+ <P>
+ Autoconf requires version 1.4 or above of GNU M4 because it uses
+ frozen state files.
+
+
+ <P>
+ Since only software maintainers need to use Autoconf, and since GNU
+ M4 is simple to configure and install, it seems reasonable to require
+ GNU M4 to be installed also. Many maintainers of GNU and
+ other free software already have most of the GNU utilities
+ installed, since they prefer them.
+
+
+
+
+ <H2><A NAME="SEC172" HREF="autoconf_toc.html#TOC172">How Can I Bootstrap?</A></H2>
+
+
+ <PRE>
+ If Autoconf requires GNU M4 and GNU M4 has an Autoconf
+ @command{configure} script, how do I bootstrap? It seems like a chicken
+ and egg problem!
+ </PRE>
+
+ <P>
+ This is a misunderstanding. Although GNU M4 does come with a
+ @command{configure} script produced by Autoconf, Autoconf is not required
+ in order to run the script and install GNU M4. Autoconf is only
+ required if you want to change the M4 @command{configure} script, which few
+ people have to do (mainly its maintainer).
+
+
+
+
+ <H2><A NAME="SEC173" HREF="autoconf_toc.html#TOC173">Why Not Imake?</A></H2>
+
+
+ <PRE>
+ Why not use Imake instead of @command{configure} scripts?
+ </PRE>
+
+ <P>
+ Several people have written addressing this question, so I include
+ adaptations of their explanations here.
+
+
+ <P>
+ The following answer is based on one written by Richard Pixley:
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ Autoconf generated scripts frequently work on machines that it has
+ never been set up to handle before. That is, it does a good job of
+ inferring a configuration for a new system. Imake cannot do this.
+
+
+ <P>
+ Imake uses a common database of host specific data. For X11, this makes
+ sense because the distribution is made as a collection of tools, by one
+ central authority who has control over the database.
+
+
+ <P>
+ GNU tools are not released this way. Each GNU tool has a
+ maintainer; these maintainers are scattered across the world. Using a
+ common database would be a maintenance nightmare. Autoconf may appear
+ to be this kind of database, but in fact it is not. Instead of listing
+ host dependencies, it lists program requirements.
+
+
+ <P>
+ If you view the GNU suite as a collection of native tools, then the
+ problems are similar. But the GNU development tools can be
+ configured as cross tools in almost any host+target permutation. All of
+ these configurations can be installed concurrently. They can even be
+ configured to share host independent files across hosts. Imake doesn't
+ address these issues.
+
+
+ <P>
+ Imake templates are a form of standardization. The GNU coding
+ standards address the same issues without necessarily imposing the same
+ restrictions.
+ </BLOCKQUOTE>
+
+ <P>
+ Here is some further explanation, written by Per Bothner:
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ One of the advantages of Imake is that it easy to generate large
+ Makefiles using <CODE>cpp</CODE>'s <SAMP>`#include'</SAMP> and macro mechanisms.
+ However, <CODE>cpp</CODE> is not programmable: it has limited conditional
+ facilities, and no looping. And <CODE>cpp</CODE> cannot inspect its
+ environment.
+
+
+ <P>
+ All of these problems are solved by using <CODE>sh</CODE> instead of
+ <CODE>cpp</CODE>. The shell is fully programmable, has macro substitution,
+ can execute (or source) other shell scripts, and can inspect its
+ environment.
+ </BLOCKQUOTE>
+
+ <P>
+ Paul Eggert elaborates more:
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ With Autoconf, installers need not assume that Imake itself is already
+ installed and working well. This may not seem like much of an advantage
+ to people who are accustomed to Imake. But on many hosts Imake is not
+ installed or the default installation is not working well, and requiring
+ Imake to install a package hinders the acceptance of that package on
+ those hosts. For example, the Imake template and configuration files
+ might not be installed properly on a host, or the Imake build procedure
+ might wrongly assume that all source files are in one big directory
+ tree, or the Imake configuration might assume one compiler whereas the
+ package or the installer needs to use another, or there might be a
+ version mismatch between the Imake expected by the package and the Imake
+ supported by the host. These problems are much rarer with Autoconf,
+ where each package comes with its own independent configuration
+ processor.
+
+
+ <P>
+ Also, Imake often suffers from unexpected interactions between
+ <CODE>make</CODE> and the installer's C preprocessor. The fundamental problem
+ here is that the C preprocessor was designed to preprocess C programs,
+ not <TT>`Makefile'</TT>s. This is much less of a problem with Autoconf,
+ which uses the general-purpose preprocessor <CODE>m4</CODE>, and where the
+ package's author (rather than the installer) does the preprocessing in a
+ standard way.
+ </BLOCKQUOTE>
+
+ <P>
+ Finally, Mark Eichin notes:
+
+
+
+ <BLOCKQUOTE>
+ <P>
+ Imake isn't all that extensible, either. In order to add new features to
+ Imake, you need to provide your own project template, and duplicate most
+ of the features of the existing one. This means that for a sophisticated
+ project, using the vendor-provided Imake templates fails to provide any
+ leverage--since they don't cover anything that your own project needs
+ (unless it is an X11 program).
+
+
+ <P>
+ On the other side, though:
+
+
+ <P>
+ The one advantage that Imake has over @command{configure}:
+ <TT>`Imakefile'</TT>s tend to be much shorter (likewise, less redundant)
+ than <TT>`Makefile.in'</TT>s. There is a fix to this, however--at least
+ for the Kerberos V5 tree, we've modified things to call in common
+ <TT>`post.in'</TT> and <TT>`pre.in'</TT> <TT>`Makefile'</TT> fragments for the
+ entire tree. This means that a lot of common things don't have to be
+ duplicated, even though they normally are in @command{configure} setups.
+ </BLOCKQUOTE>
+
+
+
+ <H1><A NAME="SEC174" HREF="autoconf_toc.html#TOC174">History of Autoconf</A></H1>
+
+ <P>
+ You may be wondering, Why was Autoconf originally written? How did it
+ get into its present form? (Why does it look like gorilla spit?) If
+ you're not wondering, then this chapter contains no information useful
+ to you, and you might as well skip it. If you <EM>are</EM> wondering,
+ then let there be light...
+
+
+
+
+ <H2><A NAME="SEC175" HREF="autoconf_toc.html#TOC175">Genesis</A></H2>
+
+ <P>
+ In June 1991 I was maintaining many of the GNU utilities for the
+ Free Software Foundation. As they were ported to more platforms and
+ more programs were added, the number of @option{-D} options that users
+ had to select in the <TT>`Makefile'</TT> (around 20) became burdensome.
+ Especially for me--I had to test each new release on a bunch of
+ different systems. So I wrote a little shell script to guess some of
+ the correct settings for the fileutils package, and released it as part
+ of fileutils 2.0. That @command{configure} script worked well enough that
+ the next month I adapted it (by hand) to create similar @command{configure}
+ scripts for several other GNU utilities packages. Brian Berliner
+ also adapted one of my scripts for his CVS revision control system.
+
+
+ <P>
+ Later that summer, I learned that Richard Stallman and Richard Pixley
+ were developing similar scripts to use in the GNU compiler tools;
+ so I adapted my @command{configure} scripts to support their evolving
+ interface: using the file name <TT>`Makefile.in'</TT> as the templates;
+ adding <SAMP>`+srcdir'</SAMP>, the first option (of many); and creating
+ <TT>`config.status'</TT> files.
+
+
+
+
+ <H2><A NAME="SEC176" HREF="autoconf_toc.html#TOC176">Exodus</A></H2>
+
+ <P>
+ As I got feedback from users, I incorporated many improvements, using
+ Emacs to search and replace, cut and paste, similar changes in each of
+ the scripts. As I adapted more GNU utilities packages to use
+ @command{configure} scripts, updating them all by hand became impractical.
+ Rich Murphey, the maintainer of the GNU graphics utilities, sent me
+ mail saying that the @command{configure} scripts were great, and asking if
+ I had a tool for generating them that I could send him. No, I thought,
+ but I should! So I started to work out how to generate them. And the
+ journey from the slavery of hand-written @command{configure} scripts to the
+ abundance and ease of Autoconf began.
+
+
+ <P>
+ Cygnus @command{configure}, which was being developed at around that time,
+ is table driven; it is meant to deal mainly with a discrete number of
+ system types with a small number of mainly unguessable features (such as
+ details of the object file format). The automatic configuration system
+ that Brian Fox had developed for Bash takes a similar approach. For
+ general use, it seems to me a hopeless cause to try to maintain an
+ up-to-date database of which features each variant of each operating
+ system has. It's easier and more reliable to check for most features on
+ the fly--especially on hybrid systems that people have hacked on
+ locally or that have patches from vendors installed.
+
+
+ <P>
+ I considered using an architecture similar to that of Cygnus
+ @command{configure}, where there is a single @command{configure} script that
+ reads pieces of <TT>`configure.in'</TT> when run. But I didn't want to have
+ to distribute all of the feature tests with every package, so I settled
+ on having a different @command{configure} made from each
+ <TT>`configure.in'</TT> by a preprocessor. That approach also offered more
+ control and flexibility.
+
+
+ <P>
+ I looked briefly into using the Metaconfig package, by Larry Wall,
+ Harlan Stenn, and Raphael Manfredi, but I decided not to for several
+ reasons. The @command{Configure} scripts it produces are interactive,
+ which I find quite inconvenient; I didn't like the ways it checked for
+ some features (such as library functions); I didn't know that it was
+ still being maintained, and the @command{Configure} scripts I had
+ seen didn't work on many modern systems (such as System V R4 and NeXT);
+ it wasn't very flexible in what it could do in response to a feature's
+ presence or absence; I found it confusing to learn; and it was too big
+ and complex for my needs (I didn't realize then how much Autoconf would
+ eventually have to grow).
+
+
+ <P>
+ I considered using Perl to generate my style of @command{configure}
+ scripts, but decided that M4 was better suited to the job of simple
+ textual substitutions: it gets in the way less, because output is
+ implicit. Plus, everyone already has it. (Initially I didn't rely on
+ the GNU extensions to M4.) Also, some of my friends at the
+ University of Maryland had recently been putting M4 front ends on
+ several programs, including <CODE>tvtwm</CODE>, and I was interested in trying
+ out a new language.
+
+
+
+
+ <H2><A NAME="SEC177" HREF="autoconf_toc.html#TOC177">Leviticus</A></H2>
+
+ <P>
+ Since my @command{configure} scripts determine the system's capabilities
+ automatically, with no interactive user intervention, I decided to call
+ the program that generates them Autoconfig. But with a version number
+ tacked on, that name would be too long for old UNIX file systems,
+ so I shortened it to Autoconf.
+
+
+ <P>
+ In the fall of 1991 I called together a group of fellow questers after
+ the Holy Grail of portability (er, that is, alpha testers) to give me
+ feedback as I encapsulated pieces of my handwritten scripts in M4 macros
+ and continued to add features and improve the techniques used in the
+ checks. Prominent among the testers were Fran@,cois Pinard, who came up
+ with the idea of making an <TT>`autoconf'</TT> shell script to run <CODE>m4</CODE>
+ and check for unresolved macro calls; Richard Pixley, who suggested
+ running the compiler instead of searching the file system to find
+ include files and symbols, for more accurate results; Karl Berry, who
+ got Autoconf to configure TeX and added the macro index to the
+ documentation; and Ian Lance Taylor, who added support for creating a C
+ header file as an alternative to putting @option{-D} options in a
+ <TT>`Makefile'</TT>, so he could use Autoconf for his UUCP package.
+ The alpha testers cheerfully adjusted their files again and again as the
+ names and calling conventions of the Autoconf macros changed from
+ release to release. They all contributed many specific checks, great
+ ideas, and bug fixes.
+
+
+
+
+ <H2><A NAME="SEC178" HREF="autoconf_toc.html#TOC178">Numbers</A></H2>
+
+ <P>
+ In July 1992, after months of alpha testing, I released Autoconf 1.0,
+ and converted many GNU packages to use it. I was surprised by how
+ positive the reaction to it was. More people started using it than I
+ could keep track of, including people working on software that wasn't
+ part of the GNU Project (such as TCL, FSP, and Kerberos V5).
+ Autoconf continued to improve rapidly, as many people using the
+ @command{configure} scripts reported problems they encountered.
+
+
+ <P>
+ Autoconf turned out to be a good torture test for M4 implementations.
+ UNIX <CODE>m4</CODE> started to dump core because of the length of the
+ macros that Autoconf defined, and several bugs showed up in GNU
+ <CODE>m4</CODE> as well. Eventually, we realized that we needed to use some
+ features that only GNU M4 has. 4.3BSD <CODE>m4</CODE>, in
+ particular, has an impoverished set of builtin macros; the System V
+ version is better, but still doesn't provide everything we need.
+
+
+ <P>
+ More development occurred as people put Autoconf under more stresses
+ (and to uses I hadn't anticipated). Karl Berry added checks for X11.
+ david zuhn contributed C++ support. Fran@,cois Pinard made it diagnose
+ invalid arguments. Jim Blandy bravely coerced it into configuring
+ GNU Emacs, laying the groundwork for several later improvements.
+ Roland McGrath got it to configure the GNU C Library, wrote the
+ @command{autoheader} script to automate the creation of C header file
+ templates, and added a @option{--verbose} option to @command{configure}.
+ Noah Friedman added the @option{--autoconf-dir} option and
+ <CODE>AC_MACRODIR</CODE> environment variable. (He also coined the term
+ <EM>autoconfiscate</EM> to mean "adapt a software package to use
+ Autoconf".) Roland and Noah improved the quoting protection in
+ <CODE>AC_DEFINE</CODE> and fixed many bugs, especially when I got sick of
+ dealing with portability problems from February through June, 1993.
+
+
+
+
+ <H2><A NAME="SEC179" HREF="autoconf_toc.html#TOC179">Deuteronomy</A></H2>
+
+ <P>
+ A long wish list for major features had accumulated, and the effect of
+ several years of patching by various people had left some residual
+ cruft. In April 1994, while working for Cygnus Support, I began a major
+ revision of Autoconf. I added most of the features of the Cygnus
+ @command{configure} that Autoconf had lacked, largely by adapting the
+ relevant parts of Cygnus @command{configure} with the help of david zuhn
+ and Ken Raeburn. These features include support for using
+ <TT>`config.sub'</TT>, <TT>`config.guess'</TT>, @option{--host}, and
+ @option{--target}; making links to files; and running @command{configure}
+ scripts in subdirectories. Adding these features enabled Ken to convert
+ GNU <CODE>as</CODE>, and Rob Savoye to convert DejaGNU, to using
+ Autoconf.
+
+
+ <P>
+ I added more features in response to other peoples' requests. Many
+ people had asked for @command{configure} scripts to share the results of
+ the checks between runs, because (particularly when configuring a large
+ source tree, like Cygnus does) they were frustratingly slow. Mike
+ Haertel suggested adding site-specific initialization scripts. People
+ distributing software that had to unpack on MS-DOS asked for a way to
+ override the <TT>`.in'</TT> extension on the file names, which produced file
+ names like <TT>`config.h.in'</TT> containing two dots. Jim Avera did an
+ extensive examination of the problems with quoting in <CODE>AC_DEFINE</CODE>
+ and <CODE>AC_SUBST</CODE>; his insights led to significant improvements.
+ Richard Stallman asked that compiler output be sent to <TT>`config.log'</TT>
+ instead of <TT>`/dev/null'</TT>, to help people debug the Emacs
+ @command{configure} script.
+
+
+ <P>
+ I made some other changes because of my dissatisfaction with the quality
+ of the program. I made the messages showing results of the checks less
+ ambiguous, always printing a result. I regularized the names of the
+ macros and cleaned up coding style inconsistencies. I added some
+ auxiliary utilities that I had developed to help convert source code
+ packages to use Autoconf. With the help of Fran@,cois Pinard, I made
+ the macros not interrupt each others' messages. (That feature revealed
+ some performance bottlenecks in GNU <CODE>m4</CODE>, which he hastily
+ corrected!) I reorganized the documentation around problems people want
+ to solve. And I began a test suite, because experience had shown that
+ Autoconf has a pronounced tendency to regress when we change it.
+
+
+ <P>
+ Again, several alpha testers gave invaluable feedback, especially
+ Fran@,cois Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn,
+ and Mark Eichin.
+
+
+ <P>
+ Finally, version 2.0 was ready. And there was much rejoicing. (And I
+ have free time again. I think. Yeah, right.)
+
+
+
+
+ <H1><A NAME="SEC180" HREF="autoconf_toc.html#TOC180">Copying This Manual</A></H1>
+
+
+
+ <H2><A NAME="SEC181" HREF="autoconf_toc.html#TOC181">GNU Free Documentation License</A></H2>
+
+ <P>
+ <A NAME="IDX1035"></A>
+ Version 1.1, March 2000
+
+
+
+ <PRE>
+ Copyright (C) 2000 Free Software Foundation, Inc.
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA
+
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+ </PRE>
+
+
+ <OL>
+ <LI>
+
+ PREAMBLE
+
+ The purpose of this License is to make a manual, textbook, or other
+ written document <EM>free</EM> in the sense of freedom: to assure everyone
+ the effective freedom to copy and redistribute it, with or without
+ modifying it, either commercially or noncommercially. Secondarily,
+ this License preserves for the author and publisher a way to get
+ credit for their work, while not being considered responsible for
+ modifications made by others.
+
+ This License is a kind of "copyleft", which means that derivative
+ works of the document must themselves be free in the same sense. It
+ complements the GNU General Public License, which is a copyleft
+ license designed for free software.
+
+ We have designed this License in order to use it for manuals for free
+ software, because free software needs free documentation: a free
+ program should come with manuals providing the same freedoms that the
+ software does. But this License is not limited to software manuals;
+ it can be used for any textual work, regardless of subject matter or
+ whether it is published as a printed book. We recommend this License
+ principally for works whose purpose is instruction or reference.
+
+ <LI>
+
+ APPLICABILITY AND DEFINITIONS
+
+ This License applies to any manual or other work that contains a
+ notice placed by the copyright holder saying it can be distributed
+ under the terms of this License. The "Document", below, refers to any
+ such manual or work. Any member of the public is a licensee, and is
+ addressed as "you".
+
+ A "Modified Version" of the Document means any work containing the
+ Document or a portion of it, either copied verbatim, or with
+ modifications and/or translated into another language.
+
+ A "Secondary Section" is a named appendix or a front-matter section of
+ the Document that deals exclusively with the relationship of the
+ publishers or authors of the Document to the Document's overall subject
+ (or to related matters) and contains nothing that could fall directly
+ within that overall subject. (For example, if the Document is in part a
+ textbook of mathematics, a Secondary Section may not explain any
+ mathematics.) The relationship could be a matter of historical
+ connection with the subject or with related matters, or of legal,
+ commercial, philosophical, ethical or political position regarding
+ them.
+
+ The "Invariant Sections" are certain Secondary Sections whose titles
+ are designated, as being those of Invariant Sections, in the notice
+ that says that the Document is released under this License.
+
+ The "Cover Texts" are certain short passages of text that are listed,
+ as Front-Cover Texts or Back-Cover Texts, in the notice that says that
+ the Document is released under this License.
+
+ A "Transparent" copy of the Document means a machine-readable copy,
+ represented in a format whose specification is available to the
+ general public, whose contents can be viewed and edited directly and
+ straightforwardly with generic text editors or (for images composed of
+ pixels) generic paint programs or (for drawings) some widely available
+ drawing editor, and that is suitable for input to text formatters or
+ for automatic translation to a variety of formats suitable for input
+ to text formatters. A copy made in an otherwise Transparent file
+ format whose markup has been designed to thwart or discourage
+ subsequent modification by readers is not Transparent. A copy that is
+ not "Transparent" is called "Opaque".
+
+ Examples of suitable formats for Transparent copies include plain
+ ASCII without markup, Texinfo input format, LaTeX input format,
+ @acronym{SGML} or @acronym{XML} using a publicly available
+ @acronym{DTD}, and standard-conforming simple @acronym{HTML} designed
+ for human modification. Opaque formats include PostScript,
+ @acronym{PDF}, proprietary formats that can be read and edited only by
+ proprietary word processors, @acronym{SGML} or @acronym{XML} for which
+ the @acronym{DTD} and/or processing tools are not generally available,
+ and the machine-generated @acronym{HTML} produced by some word
+ processors for output purposes only.
+
+ The "Title Page" means, for a printed book, the title page itself,
+ plus such following pages as are needed to hold, legibly, the material
+ this License requires to appear in the title page. For works in
+ formats which do not have any title page as such, "Title Page" means
+ the text near the most prominent appearance of the work's title,
+ preceding the beginning of the body of the text.
+
+ <LI>
+
+ VERBATIM COPYING
+
+ You may copy and distribute the Document in any medium, either
+ commercially or noncommercially, provided that this License, the
+ copyright notices, and the license notice saying this License applies
+ to the Document are reproduced in all copies, and that you add no other
+ conditions whatsoever to those of this License. You may not use
+ technical measures to obstruct or control the reading or further
+ copying of the copies you make or distribute. However, you may accept
+ compensation in exchange for copies. If you distribute a large enough
+ number of copies you must also follow the conditions in section 3.
+
+ You may also lend copies, under the same conditions stated above, and
+ you may publicly display copies.
+
+ <LI>
+
+ COPYING IN QUANTITY
+
+ If you publish printed copies of the Document numbering more than 100,
+ and the Document's license notice requires Cover Texts, you must enclose
+ the copies in covers that carry, clearly and legibly, all these Cover
+ Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
+ the back cover. Both covers must also clearly and legibly identify
+ you as the publisher of these copies. The front cover must present
+ the full title with all words of the title equally prominent and
+ visible. You may add other material on the covers in addition.
+ Copying with changes limited to the covers, as long as they preserve
+ the title of the Document and satisfy these conditions, can be treated
+ as verbatim copying in other respects.
+
+ If the required texts for either cover are too voluminous to fit
+ legibly, you should put the first ones listed (as many as fit
+ reasonably) on the actual cover, and continue the rest onto adjacent
+ pages.
+
+ If you publish or distribute Opaque copies of the Document numbering
+ more than 100, you must either include a machine-readable Transparent
+ copy along with each Opaque copy, or state in or with each Opaque copy
+ a publicly-accessible computer-network location containing a complete
+ Transparent copy of the Document, free of added material, which the
+ general network-using public has access to download anonymously at no
+ charge using public-standard network protocols. If you use the latter
+ option, you must take reasonably prudent steps, when you begin
+ distribution of Opaque copies in quantity, to ensure that this
+ Transparent copy will remain thus accessible at the stated location
+ until at least one year after the last time you distribute an Opaque
+ copy (directly or through your agents or retailers) of that edition to
+ the public.
+
+ It is requested, but not required, that you contact the authors of the
+ Document well before redistributing any large number of copies, to give
+ them a chance to provide you with an updated version of the Document.
+
+ <LI>
+
+ MODIFICATIONS
+
+ You may copy and distribute a Modified Version of the Document under
+ the conditions of sections 2 and 3 above, provided that you release
+ the Modified Version under precisely this License, with the Modified
+ Version filling the role of the Document, thus licensing distribution
+ and modification of the Modified Version to whoever possesses a copy
+ of it. In addition, you must do these things in the Modified Version:
+
+
+ <OL>
+ <LI>
+
+ Use in the Title Page (and on the covers, if any) a title distinct
+ from that of the Document, and from those of previous versions
+ (which should, if there were any, be listed in the History section
+ of the Document). You may use the same title as a previous version
+ if the original publisher of that version gives permission.
+
+ <LI>
+
+ List on the Title Page, as authors, one or more persons or entities
+ responsible for authorship of the modifications in the Modified
+ Version, together with at least five of the principal authors of the
+ Document (all of its principal authors, if it has less than five).
+
+ <LI>
+
+ State on the Title page the name of the publisher of the
+ Modified Version, as the publisher.
+
+ <LI>
+
+ Preserve all the copyright notices of the Document.
+
+ <LI>
+
+ Add an appropriate copyright notice for your modifications
+ adjacent to the other copyright notices.
+
+ <LI>
+
+ Include, immediately after the copyright notices, a license notice
+ giving the public permission to use the Modified Version under the
+ terms of this License, in the form shown in the Addendum below.
+
+ <LI>
+
+ Preserve in that license notice the full lists of Invariant Sections
+ and required Cover Texts given in the Document's license notice.
+
+ <LI>
+
+ Include an unaltered copy of this License.
+
+ <LI>
+
+ Preserve the section entitled "History", and its title, and add to
+ it an item stating at least the title, year, new authors, and
+ publisher of the Modified Version as given on the Title Page. If
+ there is no section entitled "History" in the Document, create one
+ stating the title, year, authors, and publisher of the Document as
+ given on its Title Page, then add an item describing the Modified
+ Version as stated in the previous sentence.
+
+ <LI>
+
+ Preserve the network location, if any, given in the Document for
+ public access to a Transparent copy of the Document, and likewise
+ the network locations given in the Document for previous versions
+ it was based on. These may be placed in the "History" section.
+ You may omit a network location for a work that was published at
+ least four years before the Document itself, or if the original
+ publisher of the version it refers to gives permission.
+
+ <LI>
+
+ In any section entitled "Acknowledgments" or "Dedications",
+ preserve the section's title, and preserve in the section all the
+ substance and tone of each of the contributor acknowledgments
+ and/or dedications given therein.
+
+ <LI>
+
+ Preserve all the Invariant Sections of the Document,
+ unaltered in their text and in their titles. Section numbers
+ or the equivalent are not considered part of the section titles.
+
+ <LI>
+
+ Delete any section entitled "Endorsements". Such a section
+ may not be included in the Modified Version.
+
+ <LI>
+
+ Do not retitle any existing section as "Endorsements"
+ or to conflict in title with any Invariant Section.
+ </OL>
+
+ If the Modified Version includes new front-matter sections or
+ appendices that qualify as Secondary Sections and contain no material
+ copied from the Document, you may at your option designate some or all
+ of these sections as invariant. To do this, add their titles to the
+ list of Invariant Sections in the Modified Version's license notice.
+ These titles must be distinct from any other section titles.
+
+ You may add a section entitled "Endorsements", provided it contains
+ nothing but endorsements of your Modified Version by various
+ parties--for example, statements of peer review or that the text has
+ been approved by an organization as the authoritative definition of a
+ standard.
+
+ You may add a passage of up to five words as a Front-Cover Text, and a
+ passage of up to 25 words as a Back-Cover Text, to the end of the list
+ of Cover Texts in the Modified Version. Only one passage of
+ Front-Cover Text and one of Back-Cover Text may be added by (or
+ through arrangements made by) any one entity. If the Document already
+ includes a cover text for the same cover, previously added by you or
+ by arrangement made by the same entity you are acting on behalf of,
+ you may not add another; but you may replace the old one, on explicit
+ permission from the previous publisher that added the old one.
+
+ The author(s) and publisher(s) of the Document do not by this License
+ give permission to use their names for publicity for or to assert or
+ imply endorsement of any Modified Version.
+
+ <LI>
+
+ COMBINING DOCUMENTS
+
+ You may combine the Document with other documents released under this
+ License, under the terms defined in section 4 above for modified
+ versions, provided that you include in the combination all of the
+ Invariant Sections of all of the original documents, unmodified, and
+ list them all as Invariant Sections of your combined work in its
+ license notice.
+
+ The combined work need only contain one copy of this License, and
+ multiple identical Invariant Sections may be replaced with a single
+ copy. If there are multiple Invariant Sections with the same name but
+ different contents, make the title of each such section unique by
+ adding at the end of it, in parentheses, the name of the original
+ author or publisher of that section if known, or else a unique number.
+ Make the same adjustment to the section titles in the list of
+ Invariant Sections in the license notice of the combined work.
+
+ In the combination, you must combine any sections entitled "History"
+ in the various original documents, forming one section entitled
+ "History"; likewise combine any sections entitled "Acknowledgments",
+ and any sections entitled "Dedications". You must delete all sections
+ entitled "Endorsements."
+
+ <LI>
+
+ COLLECTIONS OF DOCUMENTS
+
+ You may make a collection consisting of the Document and other documents
+ released under this License, and replace the individual copies of this
+ License in the various documents with a single copy that is included in
+ the collection, provided that you follow the rules of this License for
+ verbatim copying of each of the documents in all other respects.
+
+ You may extract a single document from such a collection, and distribute
+ it individually under this License, provided you insert a copy of this
+ License into the extracted document, and follow this License in all
+ other respects regarding verbatim copying of that document.
+
+ <LI>
+
+ AGGREGATION WITH INDEPENDENT WORKS
+
+ A compilation of the Document or its derivatives with other separate
+ and independent documents or works, in or on a volume of a storage or
+ distribution medium, does not as a whole count as a Modified Version
+ of the Document, provided no compilation copyright is claimed for the
+ compilation. Such a compilation is called an "aggregate", and this
+ License does not apply to the other self-contained works thus compiled
+ with the Document, on account of their being thus compiled, if they
+ are not themselves derivative works of the Document.
+
+ If the Cover Text requirement of section 3 is applicable to these
+ copies of the Document, then if the Document is less than one quarter
+ of the entire aggregate, the Document's Cover Texts may be placed on
+ covers that surround only the Document within the aggregate.
+ Otherwise they must appear on covers around the whole aggregate.
+
+ <LI>
+
+ TRANSLATION
+
+ Translation is considered a kind of modification, so you may
+ distribute translations of the Document under the terms of section 4.
+ Replacing Invariant Sections with translations requires special
+ permission from their copyright holders, but you may include
+ translations of some or all Invariant Sections in addition to the
+ original versions of these Invariant Sections. You may include a
+ translation of this License provided that you also include the
+ original English version of this License. In case of a disagreement
+ between the translation and the original English version of this
+ License, the original English version will prevail.
+
+ <LI>
+
+ TERMINATION
+
+ You may not copy, modify, sublicense, or distribute the Document except
+ as expressly provided for under this License. Any other attempt to
+ copy, modify, sublicense or distribute the Document is void, and will
+ automatically terminate your rights under this License. However,
+ parties who have received copies, or rights, from you under this
+ License will not have their licenses terminated so long as such
+ parties remain in full compliance.
+
+ <LI>
+
+ FUTURE REVISIONS OF THIS LICENSE
+
+ The Free Software Foundation may publish new, revised versions
+ of the GNU Free Documentation License from time to time. Such new
+ versions will be similar in spirit to the present version, but may
+ differ in detail to address new problems or concerns. See
+ <A HREF="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</A>.
+
+ Each version of the License is given a distinguishing version number.
+ If the Document specifies that a particular numbered version of this
+ License "or any later version" applies to it, you have the option of
+ following the terms and conditions either of that specified version or
+ of any later version that has been published (not as a draft) by the
+ Free Software Foundation. If the Document does not specify a version
+ number of this License, you may choose any version ever published (not
+ as a draft) by the Free Software Foundation.
+ </OL>
+
+
+
+ <H3><A NAME="SEC182" HREF="autoconf_toc.html#TOC182">ADDENDUM: How to use this License for your documents</A></H3>
+
+ <P>
+ To use this License in a document you have written, include a copy of
+ the License in the document and put the following copyright and
+ license notices just after the title page:
+
+
+
+ <PRE>
+ Copyright (C) <VAR>year</VAR> <VAR>your name</VAR>.
+ Permission is granted to copy, distribute and/or modify this document
+ under the terms of the GNU Free Documentation License, Version 1.1
+ or any later version published by the Free Software Foundation;
+ with the Invariant Sections being <VAR>list their titles</VAR>, with the
+ Front-Cover Texts being <VAR>list</VAR>, and with the Back-Cover Texts being <VAR>list</VAR>.
+ A copy of the license is included in the section entitled ``GNU
+ Free Documentation License''.
+ </PRE>
+
+ <P>
+ If you have no Invariant Sections, write "with no Invariant Sections"
+ instead of saying which ones are invariant. If you have no
+ Front-Cover Texts, write "no Front-Cover Texts" instead of
+ "Front-Cover Texts being <VAR>list</VAR>"; likewise for Back-Cover Texts.
+
+
+ <P>
+ If your document contains nontrivial examples of program code, we
+ recommend releasing these examples in parallel under your choice of
+ free software license, such as the GNU General Public License,
+ to permit their use in free software.
+
+
+
+
+ <H1><A NAME="SEC183" HREF="autoconf_toc.html#TOC183">Indices</A></H1>
+
+
+
+ <H2><A NAME="SEC184" HREF="autoconf_toc.html#TOC184">Environment Variable Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the environment variables that Autoconf
+ checks.
+
+
+ <P>
+ Jump to:
+ <A HREF="#evindex_c">c</A>
+ -
+ <A HREF="#evindex_i">i</A>
+ -
+ <A HREF="#evindex_l">l</A>
+ -
+ <A HREF="#evindex_n">n</A>
+ -
+ <A HREF="#evindex_p">p</A>
+ -
+ <A HREF="#evindex_r">r</A>
+ -
+ <A HREF="#evindex_s">s</A>
+ -
+ <A HREF="#evindex_w">w</A>
+ <P>
+ <H2><A NAME="evindex_c">c</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX698">CDPATH</A>
+ <LI><A HREF="autoconf.html#IDX796">CONFIG_COMMANDS</A>
+ <LI><A HREF="autoconf.html#IDX798">CONFIG_FILES</A>
+ <LI><A HREF="autoconf.html#IDX800">CONFIG_HEADERS</A>
+ <LI><A HREF="autoconf.html#IDX802">CONFIG_LINKS</A>
+ <LI><A HREF="autoconf.html#IDX792">CONFIG_SHELL</A>
+ <LI><A HREF="autoconf.html#IDX787">CONFIG_SITE</A>
+ <LI><A HREF="autoconf.html#IDX794">CONFIG_STATUS</A>
+ </DIR>
+ <H2><A NAME="evindex_i">i</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX699">IFS</A>
+ </DIR>
+ <H2><A NAME="evindex_l">l</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX700">LANG</A>
+ <LI><A HREF="autoconf.html#IDX707">LANGUAGE</A>
+ <LI><A HREF="autoconf.html#IDX701">LC_ALL</A>
+ <LI><A HREF="autoconf.html#IDX702">LC_COLLATE</A>
+ <LI><A HREF="autoconf.html#IDX703">LC_CTYPE</A>
+ <LI><A HREF="autoconf.html#IDX704">LC_MESSAGES</A>
+ <LI><A HREF="autoconf.html#IDX705">LC_NUMERIC</A>
+ <LI><A HREF="autoconf.html#IDX706">LC_TIME</A>
+ <LI><A HREF="autoconf.html#IDX708">LINENO</A>
+ </DIR>
+ <H2><A NAME="evindex_n">n</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX709">NULLCMD</A>
+ </DIR>
+ <H2><A NAME="evindex_p">p</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX711">PATH_SEPARATOR</A>
+ </DIR>
+ <H2><A NAME="evindex_r">r</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX712">RANDOM</A>
+ </DIR>
+ <H2><A NAME="evindex_s">s</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX807">SIMPLE_BACKUP_SUFFIX</A>
+ <LI><A HREF="autoconf.html#IDX710">status</A>
+ </DIR>
+ <H2><A NAME="evindex_w">w</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX11">WARNINGS</A>, <A HREF="autoconf.html#IDX127">WARNINGS</A>, <A HREF="autoconf.html#IDX632">WARNINGS</A>
+ </DIR>
+
+
+
+
+ <H2><A NAME="SEC185" HREF="autoconf_toc.html#TOC185">Output Variable Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the variables that Autoconf can
+ substitute into files that it creates, typically one or more
+ <TT>`Makefile'</TT>s. See section <A HREF="autoconf.html#SEC81">Setting Output Variables</A>, for more information
+ on how this is done.
+
+
+ <P>
+ Jump to:
+ <A HREF="#ovindex_a">a</A>
+ -
+ <A HREF="#ovindex_b">b</A>
+ -
+ <A HREF="#ovindex_c">c</A>
+ -
+ <A HREF="#ovindex_d">d</A>
+ -
+ <A HREF="#ovindex_e">e</A>
+ -
+ <A HREF="#ovindex_f">f</A>
+ -
+ <A HREF="#ovindex_g">g</A>
+ -
+ <A HREF="#ovindex_h">h</A>
+ -
+ <A HREF="#ovindex_i">i</A>
+ -
+ <A HREF="#ovindex_k">k</A>
+ -
+ <A HREF="#ovindex_l">l</A>
+ -
+ <A HREF="#ovindex_m">m</A>
+ -
+ <A HREF="#ovindex_n">n</A>
+ -
+ <A HREF="#ovindex_o">o</A>
+ -
+ <A HREF="#ovindex_p">p</A>
+ -
+ <A HREF="#ovindex_r">r</A>
+ -
+ <A HREF="#ovindex_s">s</A>
+ -
+ <A HREF="#ovindex_t">t</A>
+ -
+ <A HREF="#ovindex_x">x</A>
+ -
+ <A HREF="#ovindex_y">y</A>
+ <P>
+ <H2><A NAME="ovindex_a">a</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX78">abs_builddir</A>
+ <LI><A HREF="autoconf.html#IDX86">abs_srcdir</A>
+ <LI><A HREF="autoconf.html#IDX82">abs_top_builddir</A>
+ <LI><A HREF="autoconf.html#IDX90">abs_top_srcdir</A>
+ <LI><A HREF="autoconf.html#IDX220">ALLOCA</A>
+ <LI><A HREF="autoconf.html#IDX160">AWK</A>
+ </DIR>
+ <H2><A NAME="ovindex_b">b</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX92">bindir</A>
+ <LI><A HREF="autoconf.html#IDX758">build</A>
+ <LI><A HREF="autoconf.html#IDX753">build_alias</A>
+ <LI><A HREF="autoconf.html#IDX759">build_cpu</A>
+ <LI><A HREF="autoconf.html#IDX761">build_os</A>
+ <LI><A HREF="autoconf.html#IDX760">build_vendor</A>
+ <LI><A HREF="autoconf.html#IDX76">builddir</A>
+ </DIR>
+ <H2><A NAME="ovindex_c">c</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX465">CC</A>, <A HREF="autoconf.html#IDX472">CC</A>, <A HREF="autoconf.html#IDX505">CC</A>, <A HREF="autoconf.html#IDX550">CC</A>
+ <LI><A HREF="autoconf.html#IDX54">CFLAGS</A>, <A HREF="autoconf.html#IDX466">CFLAGS</A>
+ <LI><A HREF="autoconf.html#IDX56">configure_input</A>
+ <LI><A HREF="autoconf.html#IDX475">CPP</A>
+ <LI><A HREF="autoconf.html#IDX58">CPPFLAGS</A>
+ <LI><A HREF="autoconf.html#IDX751">cross_compiling</A>
+ <LI><A HREF="autoconf.html#IDX508">CXX</A>
+ <LI><A HREF="autoconf.html#IDX512">CXXCPP</A>
+ <LI><A HREF="autoconf.html#IDX60">CXXFLAGS</A>, <A HREF="autoconf.html#IDX509">CXXFLAGS</A>
+ </DIR>
+ <H2><A NAME="ovindex_d">d</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX94">datadir</A>
+ <LI><A HREF="autoconf.html#IDX62">DEFS</A>
+ </DIR>
+ <H2><A NAME="ovindex_e">e</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX66">ECHO_C</A>
+ <LI><A HREF="autoconf.html#IDX67">ECHO_N</A>
+ <LI><A HREF="autoconf.html#IDX68">ECHO_T</A>
+ <LI><A HREF="autoconf.html#IDX96">exec_prefix</A>
+ <LI><A HREF="autoconf.html#IDX459">EXEEXT</A>, <A HREF="autoconf.html#IDX842">EXEEXT</A>
+ </DIR>
+ <H2><A NAME="ovindex_f">f</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX515">F77</A>
+ <LI><A HREF="autoconf.html#IDX70">FFLAGS</A>, <A HREF="autoconf.html#IDX516">FFLAGS</A>
+ <LI><A HREF="autoconf.html#IDX522">FLIBS</A>
+ </DIR>
+ <H2><A NAME="ovindex_g">g</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX249">GETGROUPS_LIBS</A>
+ <LI><A HREF="autoconf.html#IDX265">GETLOADAVG_LIBS</A>
+ </DIR>
+ <H2><A NAME="ovindex_h">h</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX764">host</A>
+ <LI><A HREF="autoconf.html#IDX754">host_alias</A>
+ <LI><A HREF="autoconf.html#IDX765">host_cpu</A>
+ <LI><A HREF="autoconf.html#IDX767">host_os</A>
+ <LI><A HREF="autoconf.html#IDX766">host_vendor</A>
+ </DIR>
+ <H2><A NAME="ovindex_i">i</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX98">includedir</A>
+ <LI><A HREF="autoconf.html#IDX100">infodir</A>
+ <LI><A HREF="autoconf.html#IDX163">INSTALL</A>
+ <LI><A HREF="autoconf.html#IDX165">INSTALL_DATA</A>
+ <LI><A HREF="autoconf.html#IDX164">INSTALL_PROGRAM</A>
+ <LI><A HREF="autoconf.html#IDX166">INSTALL_SCRIPT</A>
+ </DIR>
+ <H2><A NAME="ovindex_k">k</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX264">KMEM_GROUP</A>
+ </DIR>
+ <H2><A NAME="ovindex_l">l</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX72">LDFLAGS</A>
+ <LI><A HREF="autoconf.html#IDX169">LEX</A>
+ <LI><A HREF="autoconf.html#IDX172">LEX_OUTPUT_ROOT</A>
+ <LI><A HREF="autoconf.html#IDX170">LEXLIB</A>
+ <LI><A HREF="autoconf.html#IDX102">libdir</A>
+ <LI><A HREF="autoconf.html#IDX104">libexecdir</A>
+ <LI><A HREF="autoconf.html#IDX262">LIBOBJS</A>, <A HREF="autoconf.html#IDX285">LIBOBJS</A>, <A HREF="autoconf.html#IDX289">LIBOBJS</A>, <A HREF="autoconf.html#IDX359">LIBOBJS</A>, <A HREF="autoconf.html#IDX366">LIBOBJS</A>, <A HREF="autoconf.html#IDX417">LIBOBJS</A>
+ <LI><A HREF="autoconf.html#IDX74">LIBS</A>, <A HREF="autoconf.html#IDX563">LIBS</A>, <A HREF="autoconf.html#IDX952">LIBS</A>, <A HREF="autoconf.html#IDX1011">LIBS</A>
+ <LI><A HREF="autoconf.html#IDX175">LN_S</A>
+ <LI><A HREF="autoconf.html#IDX106">localstatedir</A>
+ </DIR>
+ <H2><A NAME="ovindex_m">m</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX108">mandir</A>
+ </DIR>
+ <H2><A NAME="ovindex_n">n</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX263">NEED_SETGID</A>
+ </DIR>
+ <H2><A NAME="ovindex_o">o</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX460">OBJEXT</A>, <A HREF="autoconf.html#IDX919">OBJEXT</A>
+ <LI><A HREF="autoconf.html#IDX110">oldincludedir</A>
+ </DIR>
+ <H2><A NAME="ovindex_p">p</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX30">PACKAGE_BUGREPORT</A>
+ <LI><A HREF="autoconf.html#IDX18">PACKAGE_NAME</A>
+ <LI><A HREF="autoconf.html#IDX27">PACKAGE_STRING</A>
+ <LI><A HREF="autoconf.html#IDX21">PACKAGE_TARNAME</A>
+ <LI><A HREF="autoconf.html#IDX24">PACKAGE_VERSION</A>
+ <LI><A HREF="autoconf.html#IDX327">POW_LIB</A>
+ <LI><A HREF="autoconf.html#IDX112">prefix</A>
+ <LI><A HREF="autoconf.html#IDX786">program_transform_name</A>
+ </DIR>
+ <H2><A NAME="ovindex_r">r</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX178">RANLIB</A>
+ </DIR>
+ <H2><A NAME="ovindex_s">s</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX114">sbindir</A>
+ <LI><A HREF="autoconf.html#IDX50">SET_MAKE</A>
+ <LI><A HREF="autoconf.html#IDX116">sharedstatedir</A>
+ <LI><A HREF="autoconf.html#IDX84">srcdir</A>
+ <LI><A HREF="autoconf.html#IDX151">subdirs</A>
+ <LI><A HREF="autoconf.html#IDX118">sysconfdir</A>
+ </DIR>
+ <H2><A NAME="ovindex_t">t</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX770">target</A>
+ <LI><A HREF="autoconf.html#IDX755">target_alias</A>
+ <LI><A HREF="autoconf.html#IDX771">target_cpu</A>
+ <LI><A HREF="autoconf.html#IDX773">target_os</A>
+ <LI><A HREF="autoconf.html#IDX772">target_vendor</A>
+ <LI><A HREF="autoconf.html#IDX80">top_builddir</A>
+ <LI><A HREF="autoconf.html#IDX88">top_srcdir</A>
+ </DIR>
+ <H2><A NAME="ovindex_x">x</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX539">X_CFLAGS</A>
+ <LI><A HREF="autoconf.html#IDX541">X_EXTRA_LIBS</A>
+ <LI><A HREF="autoconf.html#IDX540">X_LIBS</A>
+ <LI><A HREF="autoconf.html#IDX542">X_PRE_LIBS</A>
+ </DIR>
+ <H2><A NAME="ovindex_y">y</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX181">YACC</A>
+ </DIR>
+
+
+
+
+ <H2><A NAME="SEC186" HREF="autoconf_toc.html#TOC186">Preprocessor Symbol Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the C preprocessor symbols that the
+ Autoconf macros define. To work with Autoconf, C source code needs to
+ use these names in <CODE>#if</CODE> directives.
+
+
+ <P>
+ Jump to:
+ <A HREF="#cvindex__">_</A>
+ -
+ <A HREF="#cvindex_c">c</A>
+ -
+ <A HREF="#cvindex_d">d</A>
+ -
+ <A HREF="#cvindex_f">f</A>
+ -
+ <A HREF="#cvindex_g">g</A>
+ -
+ <A HREF="#cvindex_h">h</A>
+ -
+ <A HREF="#cvindex_i">i</A>
+ -
+ <A HREF="#cvindex_l">l</A>
+ -
+ <A HREF="#cvindex_m">m</A>
+ -
+ <A HREF="#cvindex_n">n</A>
+ -
+ <A HREF="#cvindex_o">o</A>
+ -
+ <A HREF="#cvindex_p">p</A>
+ -
+ <A HREF="#cvindex_r">r</A>
+ -
+ <A HREF="#cvindex_s">s</A>
+ -
+ <A HREF="#cvindex_t">t</A>
+ -
+ <A HREF="#cvindex_u">u</A>
+ -
+ <A HREF="#cvindex_v">v</A>
+ -
+ <A HREF="#cvindex_w">w</A>
+ -
+ <A HREF="#cvindex_x">x</A>
+ -
+ <A HREF="#cvindex_y">y</A>
+ <P>
+ <H2><A NAME="cvindex__">_</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX491">__CHAR_UNSIGNED__</A>
+ <LI><A HREF="autoconf.html#IDX501">__PROTOTYPES</A>
+ <LI><A HREF="autoconf.html#IDX560">_ALL_SOURCE</A>
+ <LI><A HREF="autoconf.html#IDX548">_FILE_OFFSET_BITS</A>
+ <LI><A HREF="autoconf.html#IDX549">_LARGE_FILES</A>
+ <LI><A HREF="autoconf.html#IDX245">_LARGEFILE_SOURCE</A>
+ <LI><A HREF="autoconf.html#IDX566">_MINIX</A>
+ <LI><A HREF="autoconf.html#IDX568">_POSIX_1_SOURCE</A>
+ <LI><A HREF="autoconf.html#IDX567">_POSIX_SOURCE</A>
+ <LI><A HREF="autoconf.html#IDX387">_POSIX_VERSION</A>
+ </DIR>
+ <H2><A NAME="cvindex_c">c</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX218">C_ALLOCA</A>
+ <LI><A HREF="autoconf.html#IDX261">C_GETLOADAVG</A>
+ <LI><A HREF="autoconf.html#IDX227">CLOSEDIR_VOID</A>
+ <LI><A HREF="autoconf.html#IDX482">const</A>
+ </DIR>
+ <H2><A NAME="cvindex_d">d</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX254">DGUX</A>
+ <LI><A HREF="autoconf.html#IDX834">DIRENT</A>
+ </DIR>
+ <H2><A NAME="cvindex_f">f</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX525">F77_DUMMY_MAIN</A>
+ <LI><A HREF="autoconf.html#IDX531">F77_FUNC</A>
+ <LI><A HREF="autoconf.html#IDX532">F77_FUNC_</A>
+ <LI><A HREF="autoconf.html#IDX528">F77_MAIN</A>
+ <LI><A HREF="autoconf.html#IDX519">F77_NO_MINUS_C_MINUS_O</A>
+ </DIR>
+ <H2><A NAME="cvindex_g">g</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX435">GETGROUPS_T</A>
+ <LI><A HREF="autoconf.html#IDX259">GETLODAVG_PRIVILEGED</A>
+ <LI><A HREF="autoconf.html#IDX273">GETPGRP_VOID</A>
+ <LI><A HREF="autoconf.html#IDX454">gid_t</A>
+ <LI><A HREF="autoconf.html#IDX393">GWINSZ_IN_SYS_IOCTL</A>
+ </DIR>
+ <H2><A NAME="cvindex_h">h</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX219">HAVE_ALLOCA_H</A>
+ <LI><A HREF="autoconf.html#IDX123">HAVE_CONFIG_H</A>
+ <LI><A HREF="autoconf.html#IDX332">HAVE_DECL_STRERROR_R</A>
+ <LI><A HREF="autoconf.html#IDX407">HAVE_DECL_<VAR>symbol</VAR></A>
+ <LI><A HREF="autoconf.html#IDX370">HAVE_DIRENT_H</A>
+ <LI><A HREF="autoconf.html#IDX350">HAVE_DOPRNT</A>
+ <LI><A HREF="autoconf.html#IDX356">HAVE_<VAR>function</VAR></A>
+ <LI><A HREF="autoconf.html#IDX269">HAVE_GETMNTENT</A>
+ <LI><A HREF="autoconf.html#IDX398">HAVE_<VAR>header</VAR></A>
+ <LI><A HREF="autoconf.html#IDX494">HAVE_LONG_DOUBLE</A>
+ <LI><A HREF="autoconf.html#IDX553">HAVE_LONG_FILE_NAMES</A>
+ <LI><A HREF="autoconf.html#IDX314">HAVE_LSTAT_EMPTY_STRING_BUG</A>
+ <LI><A HREF="autoconf.html#IDX293">HAVE_MMAP</A>
+ <LI><A HREF="autoconf.html#IDX371">HAVE_NDIR_H</A>
+ <LI><A HREF="autoconf.html#IDX297">HAVE_OBSTACK</A>
+ <LI><A HREF="autoconf.html#IDX975">HAVE_RESTARTABLE_SYSCALLS</A>
+ <LI><A HREF="autoconf.html#IDX412">HAVE_ST_BLKSIZE</A>
+ <LI><A HREF="autoconf.html#IDX416">HAVE_ST_BLOCKS</A>
+ <LI><A HREF="autoconf.html#IDX420">HAVE_ST_RDEV</A>
+ <LI><A HREF="autoconf.html#IDX313">HAVE_STAT_EMPTY_STRING_BUG</A>
+ <LI><A HREF="autoconf.html#IDX323">HAVE_STRCOLL</A>
+ <LI><A HREF="autoconf.html#IDX331">HAVE_STRERROR_R</A>
+ <LI><A HREF="autoconf.html#IDX337">HAVE_STRFTIME</A>
+ <LI><A HREF="autoconf.html#IDX497">HAVE_STRINGIZE</A>
+ <LI><A HREF="autoconf.html#IDX341">HAVE_STRNLEN</A>
+ <LI><A HREF="autoconf.html#IDX411">HAVE_STRUCT_STAT_ST_BLKSIZE</A>
+ <LI><A HREF="autoconf.html#IDX415">HAVE_STRUCT_STAT_ST_BLOCKS</A>
+ <LI><A HREF="autoconf.html#IDX421">HAVE_STRUCT_STAT_ST_RDEV</A>
+ <LI><A HREF="autoconf.html#IDX372">HAVE_SYS_DIR_H</A>
+ <LI><A HREF="autoconf.html#IDX373">HAVE_SYS_NDIR_H</A>
+ <LI><A HREF="autoconf.html#IDX386">HAVE_SYS_WAIT_H</A>
+ <LI><A HREF="autoconf.html#IDX427">HAVE_TM_ZONE</A>
+ <LI><A HREF="autoconf.html#IDX428">HAVE_TZNAME</A>
+ <LI><A HREF="autoconf.html#IDX345">HAVE_UTIME_NULL</A>
+ <LI><A HREF="autoconf.html#IDX237">HAVE_VFORK_H</A>
+ <LI><A HREF="autoconf.html#IDX349">HAVE_VPRINTF</A>
+ <LI><A HREF="autoconf.html#IDX855">HAVE_WAIT3</A>
+ <LI><A HREF="autoconf.html#IDX238">HAVE_WORKING_FORK</A>
+ <LI><A HREF="autoconf.html#IDX239">HAVE_WORKING_VFORK</A>
+ </DIR>
+ <H2><A NAME="cvindex_i">i</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX488">inline</A>
+ <LI><A HREF="autoconf.html#IDX880">INT_16_BITS</A>
+ </DIR>
+ <H2><A NAME="cvindex_l">l</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX899">LONG_64_BITS</A>
+ <LI><A HREF="autoconf.html#IDX278">LSTAT_FOLLOWS_SLASHED_SYMLINK</A>
+ </DIR>
+ <H2><A NAME="cvindex_m">m</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX376">MAJOR_IN_MKDEV</A>
+ <LI><A HREF="autoconf.html#IDX377">MAJOR_IN_SYSMACROS</A>
+ <LI><A HREF="autoconf.html#IDX438">mode_t</A>
+ </DIR>
+ <H2><A NAME="cvindex_n">n</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX837">NDIR</A>
+ <LI><A HREF="autoconf.html#IDX908">NEED_MEMORY_H</A>
+ <LI><A HREF="autoconf.html#IDX260">NEED_SETGID</A>
+ <LI><A HREF="autoconf.html#IDX258">NLIST_NAME_UNION</A>
+ <LI><A HREF="autoconf.html#IDX257">NLIST_STRUCT</A>
+ <LI><A HREF="autoconf.html#IDX469">NO_MINUS_C_MINUS_O</A>
+ </DIR>
+ <H2><A NAME="cvindex_o">o</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX441">off_t</A>
+ </DIR>
+ <H2><A NAME="cvindex_p">p</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX31">PACKAGE_BUGREPORT</A>
+ <LI><A HREF="autoconf.html#IDX19">PACKAGE_NAME</A>
+ <LI><A HREF="autoconf.html#IDX28">PACKAGE_STRING</A>
+ <LI><A HREF="autoconf.html#IDX22">PACKAGE_TARNAME</A>
+ <LI><A HREF="autoconf.html#IDX25">PACKAGE_VERSION</A>
+ <LI><A HREF="autoconf.html#IDX502">PARAMS</A>
+ <LI><A HREF="autoconf.html#IDX444">pid_t</A>
+ <LI><A HREF="autoconf.html#IDX500">PROTOTYPES</A>
+ </DIR>
+ <H2><A NAME="cvindex_r">r</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX447">RETSIGTYPE</A>
+ </DIR>
+ <H2><A NAME="cvindex_s">s</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX301">SELECT_TYPE_ARG1</A>
+ <LI><A HREF="autoconf.html#IDX302">SELECT_TYPE_ARG234</A>
+ <LI><A HREF="autoconf.html#IDX303">SELECT_TYPE_ARG5</A>
+ <LI><A HREF="autoconf.html#IDX307">SETPGRP_VOID</A>
+ <LI><A HREF="autoconf.html#IDX319">SETVBUF_REVERSED</A>
+ <LI><A HREF="autoconf.html#IDX450">size_t</A>
+ <LI><A HREF="autoconf.html#IDX383">STDC_HEADERS</A>
+ <LI><A HREF="autoconf.html#IDX333">STRERROR_R_CHAR_P</A>
+ <LI><A HREF="autoconf.html#IDX253">SVR4</A>
+ <LI><A HREF="autoconf.html#IDX402">SYS_SIGLIST_DECLARED</A>
+ <LI><A HREF="autoconf.html#IDX836">SYSDIR</A>
+ <LI><A HREF="autoconf.html#IDX835">SYSNDIR</A>
+ </DIR>
+ <H2><A NAME="cvindex_t">t</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX390">TIME_WITH_SYS_TIME</A>
+ <LI><A HREF="autoconf.html#IDX424">TM_IN_SYS_TIME</A>
+ </DIR>
+ <H2><A NAME="cvindex_u">u</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX453">uid_t</A>
+ <LI><A HREF="autoconf.html#IDX255">UMAX</A>
+ <LI><A HREF="autoconf.html#IDX256">UMAX4_3</A>
+ <LI><A HREF="autoconf.html#IDX992">USG</A>
+ </DIR>
+ <H2><A NAME="cvindex_v">v</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX240">vfork</A>
+ <LI><A HREF="autoconf.html#IDX485">volatile</A>
+ </DIR>
+ <H2><A NAME="cvindex_w">w</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX478">WORDS_BIGENDIAN</A>
+ </DIR>
+ <H2><A NAME="cvindex_x">x</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX543">X_DISPLAY_MISSING</A>
+ </DIR>
+ <H2><A NAME="cvindex_y">y</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX171">YYTEXT_POINTER</A>
+ </DIR>
+
+
+
+
+ <H2><A NAME="SEC187" HREF="autoconf_toc.html#TOC187">Autoconf Macro Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the Autoconf macros. To make the list
+ easier to use, the macros are listed without their preceding <SAMP>`AC_'</SAMP>.
+
+
+ <P>
+ Jump to:
+ <A HREF="#acindex_a">a</A>
+ -
+ <A HREF="#acindex_b">b</A>
+ -
+ <A HREF="#acindex_c">c</A>
+ -
+ <A HREF="#acindex_d">d</A>
+ -
+ <A HREF="#acindex_e">e</A>
+ -
+ <A HREF="#acindex_f">f</A>
+ -
+ <A HREF="#acindex_g">g</A>
+ -
+ <A HREF="#acindex_h">h</A>
+ -
+ <A HREF="#acindex_i">i</A>
+ -
+ <A HREF="#acindex_l">l</A>
+ -
+ <A HREF="#acindex_m">m</A>
+ -
+ <A HREF="#acindex_o">o</A>
+ -
+ <A HREF="#acindex_p">p</A>
+ -
+ <A HREF="#acindex_r">r</A>
+ -
+ <A HREF="#acindex_s">s</A>
+ -
+ <A HREF="#acindex_t">t</A>
+ -
+ <A HREF="#acindex_u">u</A>
+ -
+ <A HREF="#acindex_v">v</A>
+ -
+ <A HREF="#acindex_w">w</A>
+ -
+ <A HREF="#acindex_x">x</A>
+ -
+ <A HREF="#acindex_y">y</A>
+ <P>
+ <H2><A NAME="acindex_a">a</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX138">AH_BOTTOM</A>
+ <LI><A HREF="autoconf.html#IDX132">AH_TEMPLATE</A>
+ <LI><A HREF="autoconf.html#IDX135">AH_TOP</A>
+ <LI><A HREF="autoconf.html#IDX129">AH_VERBATIM</A>
+ <LI><A HREF="autoconf.html#IDX559">AIX</A>
+ <LI><A HREF="autoconf.html#IDX809">ALLOCA</A>
+ <LI><A HREF="autoconf.html#IDX811">ARG_ARRAY</A>
+ <LI><A HREF="autoconf.html#IDX779">ARG_ENABLE</A>
+ <LI><A HREF="autoconf.html#IDX785">ARG_PROGRAM</A>
+ <LI><A HREF="autoconf.html#IDX603">ARG_VAR</A>
+ <LI><A HREF="autoconf.html#IDX775">ARG_WITH</A>
+ <LI><A HREF="autoconf.html#IDX684">AU_DEFUN</A>
+ </DIR>
+ <H2><A NAME="acindex_b">b</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX681">BEFORE</A>
+ <LI><A HREF="autoconf.html#IDX139">BOTTOM</A>
+ </DIR>
+ <H2><A NAME="acindex_c">c</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX477">C_BIGENDIAN</A>
+ <LI><A HREF="autoconf.html#IDX490">C_CHAR_UNSIGNED</A>
+ <LI><A HREF="autoconf.html#IDX481">C_CONST</A>
+ <LI><A HREF="autoconf.html#IDX813">C_CROSS</A>
+ <LI><A HREF="autoconf.html#IDX487">C_INLINE</A>
+ <LI><A HREF="autoconf.html#IDX493">C_LONG_DOUBLE</A>
+ <LI><A HREF="autoconf.html#IDX499">C_PROTOTYPES</A>
+ <LI><A HREF="autoconf.html#IDX496">C_STRINGIZE</A>
+ <LI><A HREF="autoconf.html#IDX484">C_VOLATILE</A>
+ <LI><A HREF="autoconf.html#IDX608">CACHE_CHECK</A>
+ <LI><A HREF="autoconf.html#IDX611">CACHE_LOAD</A>
+ <LI><A HREF="autoconf.html#IDX613">CACHE_SAVE</A>
+ <LI><A HREF="autoconf.html#IDX606">CACHE_VAL</A>
+ <LI><A HREF="autoconf.html#IDX757">CANONICAL_BUILD</A>
+ <LI><A HREF="autoconf.html#IDX763">CANONICAL_HOST</A>
+ <LI><A HREF="autoconf.html#IDX815">CANONICAL_SYSTEM</A>
+ <LI><A HREF="autoconf.html#IDX769">CANONICAL_TARGET</A>
+ <LI><A HREF="autoconf.html#IDX817">CHAR_UNSIGNED</A>
+ <LI><A HREF="autoconf.html#IDX404">CHECK_DECL</A>
+ <LI><A HREF="autoconf.html#IDX406">CHECK_DECLS</A>
+ <LI><A HREF="autoconf.html#IDX198">CHECK_FILE</A>
+ <LI><A HREF="autoconf.html#IDX200">CHECK_FILES</A>
+ <LI><A HREF="autoconf.html#IDX353">CHECK_FUNC</A>
+ <LI><A HREF="autoconf.html#IDX355">CHECK_FUNCS</A>
+ <LI><A HREF="autoconf.html#IDX395">CHECK_HEADER</A>
+ <LI><A HREF="autoconf.html#IDX397">CHECK_HEADERS</A>
+ <LI><A HREF="autoconf.html#IDX203">CHECK_LIB</A>
+ <LI><A HREF="autoconf.html#IDX430">CHECK_MEMBER</A>
+ <LI><A HREF="autoconf.html#IDX432">CHECK_MEMBERS</A>
+ <LI><A HREF="autoconf.html#IDX183">CHECK_PROG</A>
+ <LI><A HREF="autoconf.html#IDX185">CHECK_PROGS</A>
+ <LI><A HREF="autoconf.html#IDX462">CHECK_SIZEOF</A>
+ <LI><A HREF="autoconf.html#IDX187">CHECK_TOOL</A>
+ <LI><A HREF="autoconf.html#IDX189">CHECK_TOOLS</A>
+ <LI><A HREF="autoconf.html#IDX456">CHECK_TYPE</A>, <A HREF="autoconf.html#IDX819">CHECK_TYPE</A>
+ <LI><A HREF="autoconf.html#IDX458">CHECK_TYPES</A>
+ <LI><A HREF="autoconf.html#IDX821">CHECKING</A>
+ <LI><A HREF="autoconf.html#IDX823">COMPILE_CHECK</A>
+ <LI><A HREF="autoconf.html#IDX44">CONFIG_AUX_DIR</A>
+ <LI><A HREF="autoconf.html#IDX141">CONFIG_COMMANDS</A>
+ <LI><A HREF="autoconf.html#IDX52">CONFIG_FILES</A>
+ <LI><A HREF="autoconf.html#IDX122">CONFIG_HEADERS</A>
+ <LI><A HREF="autoconf.html#IDX147">CONFIG_LINKS</A>
+ <LI><A HREF="autoconf.html#IDX42">CONFIG_SRCDIR</A>
+ <LI><A HREF="autoconf.html#IDX150">CONFIG_SUBDIRS</A>
+ <LI><A HREF="autoconf.html#IDX825">CONST</A>
+ <LI><A HREF="autoconf.html#IDX36">COPYRIGHT</A>
+ <LI><A HREF="autoconf.html#IDX827">CROSS_CHECK</A>
+ <LI><A HREF="autoconf.html#IDX829">CYGWIN</A>
+ </DIR>
+ <H2><A NAME="acindex_d">d</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX401">DECL_SYS_SIGLIST</A>
+ <LI><A HREF="autoconf.html#IDX831">DECL_YYTEXT</A>
+ <LI><A HREF="autoconf.html#IDX593">DEFINE</A>
+ <LI><A HREF="autoconf.html#IDX595">DEFINE_UNQUOTED</A>
+ <LI><A HREF="autoconf.html#IDX669">DEFUN</A>, <A HREF="autoconf.html#IDX683">DEFUN</A>
+ <LI><A HREF="autoconf.html#IDX673">DIAGNOSE</A>
+ <LI><A HREF="autoconf.html#IDX833">DIR_HEADER</A>
+ <LI><A HREF="autoconf.html#IDX839">DYNIX_SEQ</A>
+ </DIR>
+ <H2><A NAME="acindex_e">e</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX574">EGREP_CPP</A>
+ <LI><A HREF="autoconf.html#IDX572">EGREP_HEADER</A>
+ <LI><A HREF="autoconf.html#IDX844">EMXOS2</A>
+ <LI><A HREF="autoconf.html#IDX781">ENABLE</A>
+ <LI><A HREF="autoconf.html#IDX846">ERROR</A>
+ <LI><A HREF="autoconf.html#IDX841">EXEEXT</A>
+ </DIR>
+ <H2><A NAME="acindex_f">f</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX524">F77_DUMMY_MAIN</A>
+ <LI><A HREF="autoconf.html#IDX534">F77_FUNC</A>
+ <LI><A HREF="autoconf.html#IDX521">F77_LIBRARY_LDFLAGS</A>
+ <LI><A HREF="autoconf.html#IDX527">F77_MAIN</A>
+ <LI><A HREF="autoconf.html#IDX530">F77_WRAPPERS</A>
+ <LI><A HREF="autoconf.html#IDX677">FATAL</A>
+ <LI><A HREF="autoconf.html#IDX848">FIND_X</A>
+ <LI><A HREF="autoconf.html#IDX850">FIND_XTRA</A>
+ <LI><A HREF="autoconf.html#IDX217">FUNC_ALLOCA</A>
+ <LI><A HREF="autoconf.html#IDX852">FUNC_CHECK</A>
+ <LI><A HREF="autoconf.html#IDX223">FUNC_CHOWN</A>
+ <LI><A HREF="autoconf.html#IDX226">FUNC_CLOSEDIR_VOID</A>
+ <LI><A HREF="autoconf.html#IDX230">FUNC_ERROR_AT_LINE</A>
+ <LI><A HREF="autoconf.html#IDX233">FUNC_FNMATCH</A>
+ <LI><A HREF="autoconf.html#IDX236">FUNC_FORK</A>
+ <LI><A HREF="autoconf.html#IDX244">FUNC_FSEEKO</A>
+ <LI><A HREF="autoconf.html#IDX248">FUNC_GETGROUPS</A>
+ <LI><A HREF="autoconf.html#IDX252">FUNC_GETLOADAVG</A>
+ <LI><A HREF="autoconf.html#IDX268">FUNC_GETMNTENT</A>
+ <LI><A HREF="autoconf.html#IDX272">FUNC_GETPGRP</A>
+ <LI><A HREF="autoconf.html#IDX312">FUNC_LSTAT</A>
+ <LI><A HREF="autoconf.html#IDX277">FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK</A>
+ <LI><A HREF="autoconf.html#IDX281">FUNC_MALLOC</A>
+ <LI><A HREF="autoconf.html#IDX284">FUNC_MEMCMP</A>
+ <LI><A HREF="autoconf.html#IDX288">FUNC_MKTIME</A>
+ <LI><A HREF="autoconf.html#IDX292">FUNC_MMAP</A>
+ <LI><A HREF="autoconf.html#IDX296">FUNC_OBSTACK</A>
+ <LI><A HREF="autoconf.html#IDX300">FUNC_SELECT_ARGTYPES</A>
+ <LI><A HREF="autoconf.html#IDX306">FUNC_SETPGRP</A>
+ <LI><A HREF="autoconf.html#IDX318">FUNC_SETVBUF_REVERSED</A>
+ <LI><A HREF="autoconf.html#IDX311">FUNC_STAT</A>
+ <LI><A HREF="autoconf.html#IDX322">FUNC_STRCOLL</A>
+ <LI><A HREF="autoconf.html#IDX330">FUNC_STRERROR_R</A>
+ <LI><A HREF="autoconf.html#IDX336">FUNC_STRFTIME</A>
+ <LI><A HREF="autoconf.html#IDX340">FUNC_STRNLEN</A>
+ <LI><A HREF="autoconf.html#IDX326">FUNC_STRTOD</A>
+ <LI><A HREF="autoconf.html#IDX344">FUNC_UTIME_NULL</A>
+ <LI><A HREF="autoconf.html#IDX348">FUNC_VPRINTF</A>
+ <LI><A HREF="autoconf.html#IDX854">FUNC_WAIT3</A>
+ </DIR>
+ <H2><A NAME="acindex_g">g</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX857">GCC_TRADITIONAL</A>
+ <LI><A HREF="autoconf.html#IDX859">GETGROUPS_T</A>
+ <LI><A HREF="autoconf.html#IDX861">GETLOADAVG</A>
+ </DIR>
+ <H2><A NAME="acindex_h">h</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX863">HAVE_FUNCS</A>
+ <LI><A HREF="autoconf.html#IDX865">HAVE_HEADERS</A>
+ <LI><A HREF="autoconf.html#IDX867">HAVE_LIBRARY</A>
+ <LI><A HREF="autoconf.html#IDX869">HAVE_POUNDBANG</A>
+ <LI><A HREF="autoconf.html#IDX871">HEADER_CHECK</A>
+ <LI><A HREF="autoconf.html#IDX369">HEADER_DIRENT</A>
+ <LI><A HREF="autoconf.html#IDX873">HEADER_EGREP</A>
+ <LI><A HREF="autoconf.html#IDX375">HEADER_MAJOR</A>
+ <LI><A HREF="autoconf.html#IDX379">HEADER_STAT</A>
+ <LI><A HREF="autoconf.html#IDX382">HEADER_STDC</A>
+ <LI><A HREF="autoconf.html#IDX385">HEADER_SYS_WAIT</A>
+ <LI><A HREF="autoconf.html#IDX389">HEADER_TIME</A>
+ <LI><A HREF="autoconf.html#IDX392">HEADER_TIOCGWINSZ</A>
+ <LI><A HREF="autoconf.html#IDX783">HELP_STRING</A>
+ </DIR>
+ <H2><A NAME="acindex_i">i</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX16">INIT</A>, <A HREF="autoconf.html#IDX875">INIT</A>
+ <LI><A HREF="autoconf.html#IDX877">INLINE</A>
+ <LI><A HREF="autoconf.html#IDX879">INT_16_BITS</A>
+ <LI><A HREF="autoconf.html#IDX882">IRIX_SUN</A>
+ <LI><A HREF="autoconf.html#IDX562">ISC_POSIX</A>
+ </DIR>
+ <H2><A NAME="acindex_l">l</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX884">LANG_C</A>
+ <LI><A HREF="autoconf.html#IDX886">LANG_CPLUSPLUS</A>
+ <LI><A HREF="autoconf.html#IDX888">LANG_FORTRAN77</A>
+ <LI><A HREF="autoconf.html#IDX589">LANG_POP</A>
+ <LI><A HREF="autoconf.html#IDX587">LANG_PUSH</A>
+ <LI><A HREF="autoconf.html#IDX890">LANG_RESTORE</A>
+ <LI><A HREF="autoconf.html#IDX892">LANG_SAVE</A>
+ <LI><A HREF="autoconf.html#IDX358">LIBOBJ</A>
+ <LI><A HREF="autoconf.html#IDX361">LIBSOURCE</A>
+ <LI><A HREF="autoconf.html#IDX363">LIBSOURCES</A>
+ <LI><A HREF="autoconf.html#IDX894">LINK_FILES</A>
+ <LI><A HREF="autoconf.html#IDX896">LN_S</A>
+ <LI><A HREF="autoconf.html#IDX898">LONG_64_BITS</A>
+ <LI><A HREF="autoconf.html#IDX901">LONG_DOUBLE</A>
+ <LI><A HREF="autoconf.html#IDX903">LONG_FILE_NAMES</A>
+ </DIR>
+ <H2><A NAME="acindex_m">m</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX905">MAJOR_HEADER</A>
+ <LI><A HREF="autoconf.html#IDX907">MEMORY_H</A>
+ <LI><A HREF="autoconf.html#IDX910">MINGW32</A>
+ <LI><A HREF="autoconf.html#IDX565">MINIX</A>
+ <LI><A HREF="autoconf.html#IDX912">MINUS_C_MINUS_O</A>
+ <LI><A HREF="autoconf.html#IDX914">MMAP</A>
+ <LI><A HREF="autoconf.html#IDX916">MODE_T</A>
+ <LI><A HREF="autoconf.html#IDX616">MSG_CHECKING</A>
+ <LI><A HREF="autoconf.html#IDX622">MSG_ERROR</A>
+ <LI><A HREF="autoconf.html#IDX620">MSG_NOTICE</A>
+ <LI><A HREF="autoconf.html#IDX618">MSG_RESULT</A>
+ <LI><A HREF="autoconf.html#IDX624">MSG_WARN</A>
+ </DIR>
+ <H2><A NAME="acindex_o">o</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX918">OBJEXT</A>
+ <LI><A HREF="autoconf.html#IDX921">OBSOLETE</A>
+ <LI><A HREF="autoconf.html#IDX923">OFF_T</A>
+ <LI><A HREF="autoconf.html#IDX46">OUTPUT</A>, <A HREF="autoconf.html#IDX925">OUTPUT</A>
+ <LI><A HREF="autoconf.html#IDX927">OUTPUT_COMMANDS</A>
+ <LI><A HREF="autoconf.html#IDX145">OUTPUT_COMMANDS_POST</A>
+ <LI><A HREF="autoconf.html#IDX143">OUTPUT_COMMANDS_PRE</A>
+ </DIR>
+ <H2><A NAME="acindex_p">p</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX29">PACKAGE_BUGREPORT</A>
+ <LI><A HREF="autoconf.html#IDX17">PACKAGE_NAME</A>
+ <LI><A HREF="autoconf.html#IDX26">PACKAGE_STRING</A>
+ <LI><A HREF="autoconf.html#IDX20">PACKAGE_TARNAME</A>
+ <LI><A HREF="autoconf.html#IDX23">PACKAGE_VERSION</A>
+ <LI><A HREF="autoconf.html#IDX191">PATH_PROG</A>
+ <LI><A HREF="autoconf.html#IDX193">PATH_PROGS</A>
+ <LI><A HREF="autoconf.html#IDX195">PATH_TOOL</A>
+ <LI><A HREF="autoconf.html#IDX536">PATH_X</A>
+ <LI><A HREF="autoconf.html#IDX538">PATH_XTRA</A>
+ <LI><A HREF="autoconf.html#IDX929">PID_T</A>
+ <LI><A HREF="autoconf.html#IDX931">PREFIX</A>
+ <LI><A HREF="autoconf.html#IDX153">PREFIX_DEFAULT</A>
+ <LI><A HREF="autoconf.html#IDX155">PREFIX_PROGRAM</A>
+ <LI><A HREF="autoconf.html#IDX33">PREREQ</A>
+ <LI><A HREF="autoconf.html#IDX159">PROG_AWK</A>
+ <LI><A HREF="autoconf.html#IDX464">PROG_CC</A>
+ <LI><A HREF="autoconf.html#IDX468">PROG_CC_C_O</A>
+ <LI><A HREF="autoconf.html#IDX471">PROG_CC_STDC</A>
+ <LI><A HREF="autoconf.html#IDX474">PROG_CPP</A>
+ <LI><A HREF="autoconf.html#IDX507">PROG_CXX</A>
+ <LI><A HREF="autoconf.html#IDX511">PROG_CXXCPP</A>
+ <LI><A HREF="autoconf.html#IDX518">PROG_F77_C_O</A>
+ <LI><A HREF="autoconf.html#IDX514">PROG_FORTRAN</A>
+ <LI><A HREF="autoconf.html#IDX504">PROG_GCC_TRADITIONAL</A>
+ <LI><A HREF="autoconf.html#IDX162">PROG_INSTALL</A>
+ <LI><A HREF="autoconf.html#IDX168">PROG_LEX</A>
+ <LI><A HREF="autoconf.html#IDX174">PROG_LN_S</A>
+ <LI><A HREF="autoconf.html#IDX49">PROG_MAKE_SET</A>
+ <LI><A HREF="autoconf.html#IDX177">PROG_RANLIB</A>
+ <LI><A HREF="autoconf.html#IDX180">PROG_YACC</A>
+ <LI><A HREF="autoconf.html#IDX937">PROGRAM_CHECK</A>
+ <LI><A HREF="autoconf.html#IDX939">PROGRAM_EGREP</A>
+ <LI><A HREF="autoconf.html#IDX941">PROGRAM_PATH</A>
+ <LI><A HREF="autoconf.html#IDX933">PROGRAMS_CHECK</A>
+ <LI><A HREF="autoconf.html#IDX935">PROGRAMS_PATH</A>
+ </DIR>
+ <H2><A NAME="acindex_r">r</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX943">REMOTE_TAPE</A>
+ <LI><A HREF="autoconf.html#IDX365">REPLACE_FUNCS</A>
+ <LI><A HREF="autoconf.html#IDX679">REQUIRE</A>
+ <LI><A HREF="autoconf.html#IDX591">REQUIRE_CPP</A>
+ <LI><A HREF="autoconf.html#IDX945">RESTARTABLE_SYSCALLS</A>
+ <LI><A HREF="autoconf.html#IDX947">RETSIGTYPE</A>
+ <LI><A HREF="autoconf.html#IDX39">REVISION</A>
+ <LI><A HREF="autoconf.html#IDX949">RSH</A>
+ </DIR>
+ <H2><A NAME="acindex_s">s</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX951">SCO_INTL</A>
+ <LI><A HREF="autoconf.html#IDX205">SEARCH_LIBS</A>
+ <LI><A HREF="autoconf.html#IDX956">SET_MAKE</A>
+ <LI><A HREF="autoconf.html#IDX954">SETVBUF_REVERSED</A>
+ <LI><A HREF="autoconf.html#IDX960">SIZE_T</A>
+ <LI><A HREF="autoconf.html#IDX958">SIZEOF_TYPE</A>
+ <LI><A HREF="autoconf.html#IDX968">ST_BLKSIZE</A>
+ <LI><A HREF="autoconf.html#IDX970">ST_BLOCKS</A>
+ <LI><A HREF="autoconf.html#IDX972">ST_RDEV</A>
+ <LI><A HREF="autoconf.html#IDX380">STAT_MACROS_BROKEN</A>, <A HREF="autoconf.html#IDX962">STAT_MACROS_BROKEN</A>
+ <LI><A HREF="autoconf.html#IDX964">STDC_HEADERS</A>
+ <LI><A HREF="autoconf.html#IDX966">STRCOLL</A>
+ <LI><A HREF="autoconf.html#IDX410">STRUCT_ST_BLKSIZE</A>
+ <LI><A HREF="autoconf.html#IDX414">STRUCT_ST_BLOCKS</A>
+ <LI><A HREF="autoconf.html#IDX419">STRUCT_ST_RDEV</A>
+ <LI><A HREF="autoconf.html#IDX426">STRUCT_TIMEZONE</A>
+ <LI><A HREF="autoconf.html#IDX423">STRUCT_TM</A>
+ <LI><A HREF="autoconf.html#IDX597">SUBST</A>
+ <LI><A HREF="autoconf.html#IDX599">SUBST_FILE</A>
+ <LI><A HREF="autoconf.html#IDX545">SYS_INTERPRETER</A>
+ <LI><A HREF="autoconf.html#IDX547">SYS_LARGEFILE</A>
+ <LI><A HREF="autoconf.html#IDX552">SYS_LONG_FILE_NAMES</A>
+ <LI><A HREF="autoconf.html#IDX555">SYS_POSIX_TERMIOS</A>
+ <LI><A HREF="autoconf.html#IDX974">SYS_RESTARTABLE_SYSCALLS</A>
+ <LI><A HREF="autoconf.html#IDX977">SYS_SIGLIST_DECLARED</A>
+ </DIR>
+ <H2><A NAME="acindex_t">t</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX133">TEMPLATE</A>
+ <LI><A HREF="autoconf.html#IDX979">TEST_CPP</A>
+ <LI><A HREF="autoconf.html#IDX981">TEST_PROGRAM</A>
+ <LI><A HREF="autoconf.html#IDX985">TIME_WITH_SYS_TIME</A>
+ <LI><A HREF="autoconf.html#IDX983">TIMEZONE</A>
+ <LI><A HREF="autoconf.html#IDX136">TOP</A>
+ <LI><A HREF="autoconf.html#IDX576">TRY_COMPILE</A>
+ <LI><A HREF="autoconf.html#IDX570">TRY_CPP</A>
+ <LI><A HREF="autoconf.html#IDX578">TRY_LINK</A>
+ <LI><A HREF="autoconf.html#IDX580">TRY_LINK_FUNC</A>
+ <LI><A HREF="autoconf.html#IDX582">TRY_RUN</A>
+ <LI><A HREF="autoconf.html#IDX434">TYPE_GETGROUPS</A>
+ <LI><A HREF="autoconf.html#IDX437">TYPE_MODE_T</A>
+ <LI><A HREF="autoconf.html#IDX440">TYPE_OFF_T</A>
+ <LI><A HREF="autoconf.html#IDX443">TYPE_PID_T</A>
+ <LI><A HREF="autoconf.html#IDX446">TYPE_SIGNAL</A>
+ <LI><A HREF="autoconf.html#IDX449">TYPE_SIZE_T</A>
+ <LI><A HREF="autoconf.html#IDX452">TYPE_UID_T</A>
+ </DIR>
+ <H2><A NAME="acindex_u">u</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX987">UID_T</A>
+ <LI><A HREF="autoconf.html#IDX989">UNISTD_H</A>
+ <LI><A HREF="autoconf.html#IDX991">USG</A>
+ <LI><A HREF="autoconf.html#IDX994">UTIME_NULL</A>
+ </DIR>
+ <H2><A NAME="acindex_v">v</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX996">VALIDATE_CACHED_SYSTEM_TUPLE</A>
+ <LI><A HREF="autoconf.html#IDX130">VERBATIM</A>
+ <LI><A HREF="autoconf.html#IDX998">VERBOSE</A>
+ <LI><A HREF="autoconf.html#IDX1000">VFORK</A>
+ <LI><A HREF="autoconf.html#IDX1002">VPRINTF</A>
+ </DIR>
+ <H2><A NAME="acindex_w">w</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1004">WAIT3</A>
+ <LI><A HREF="autoconf.html#IDX1006">WARN</A>
+ <LI><A HREF="autoconf.html#IDX675">WARNING</A>
+ <LI><A HREF="autoconf.html#IDX777">WITH</A>
+ <LI><A HREF="autoconf.html#IDX1008">WORDS_BIGENDIAN</A>
+ </DIR>
+ <H2><A NAME="acindex_x">x</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1010">XENIX_DIR</A>
+ </DIR>
+ <H2><A NAME="acindex_y">y</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1013">YYTEXT_POINTER</A>
+ </DIR>
+
+
+
+
+ <H2><A NAME="SEC188" HREF="autoconf_toc.html#TOC188">M4 Macro Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the M4, M4sugar, and M4sh macros. To
+ make the list easier to use, the macros are listed without their
+ preceding <SAMP>`m4_'</SAMP> or <SAMP>`AS_'</SAMP>.
+
+
+ <P>
+ Jump to:
+ <A HREF="#msindex_b">b</A>
+ -
+ <A HREF="#msindex_d">d</A>
+ -
+ <A HREF="#msindex_m">m</A>
+ -
+ <A HREF="#msindex_p">p</A>
+ -
+ <A HREF="#msindex_q">q</A>
+ -
+ <A HREF="#msindex_u">u</A>
+ <P>
+ <H2><A NAME="msindex_b">b</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX652">bpatsubst</A>
+ <LI><A HREF="autoconf.html#IDX656">bregexp</A>
+ </DIR>
+ <H2><A NAME="msindex_d">d</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX642">defn</A>, <A HREF="autoconf.html#IDX654">defn</A>
+ <LI><A HREF="autoconf.html#IDX668">DIRNAME</A>
+ <LI><A HREF="autoconf.html#IDX640">dnl</A>
+ <LI><A HREF="autoconf.html#IDX660">dquote</A>
+ </DIR>
+ <H2><A NAME="msindex_m">m</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX644">m4_exit</A>
+ <LI><A HREF="autoconf.html#IDX648">m4_if</A>
+ <LI><A HREF="autoconf.html#IDX658">m4_wrap</A>
+ </DIR>
+ <H2><A NAME="msindex_p">p</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX666">pattern_allow</A>
+ <LI><A HREF="autoconf.html#IDX664">pattern_forbid</A>
+ </DIR>
+ <H2><A NAME="msindex_q">q</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX662">quote</A>
+ </DIR>
+ <H2><A NAME="msindex_u">u</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX650">undefine</A>
+ </DIR>
+
+
+
+
+ <H2><A NAME="SEC189" HREF="autoconf_toc.html#TOC189">Autotest Macro Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the Autotest macros. To make the list
+ easier to use, the macros are listed without their preceding <SAMP>`AT_'</SAMP>.
+
+
+ <P>
+ Jump to:
+ <A HREF="#atindex_c">c</A>
+ -
+ <A HREF="#atindex_d">d</A>
+ -
+ <A HREF="#atindex_i">i</A>
+ -
+ <A HREF="#atindex_k">k</A>
+ -
+ <A HREF="#atindex_s">s</A>
+ -
+ <A HREF="#atindex_t">t</A>
+ <P>
+ <H2><A NAME="atindex_c">c</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1031">CHECK</A>
+ <LI><A HREF="autoconf.html#IDX1027">CLEANUP</A>
+ </DIR>
+ <H2><A NAME="atindex_d">d</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1029">DATA</A>
+ </DIR>
+ <H2><A NAME="atindex_i">i</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1019">INIT</A>
+ </DIR>
+ <H2><A NAME="atindex_k">k</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1025">KEYWORDS</A>
+ </DIR>
+ <H2><A NAME="atindex_s">s</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1023">SETUP</A>
+ </DIR>
+ <H2><A NAME="atindex_t">t</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1021">TESTED</A>
+ </DIR>
+
+
+
+
+ <H2><A NAME="SEC190" HREF="autoconf_toc.html#TOC190">Program and Function Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the programs and functions which
+ portability is discussed in this document.
+
+
+ <P>
+ Jump to:
+ <A HREF="#prindex_@">@</A>
+ -
+ <A HREF="#prindex_a">a</A>
+ -
+ <A HREF="#prindex_c">c</A>
+ -
+ <A HREF="#prindex_e">e</A>
+ -
+ <A HREF="#prindex_f">f</A>
+ -
+ <A HREF="#prindex_g">g</A>
+ -
+ <A HREF="#prindex_l">l</A>
+ -
+ <A HREF="#prindex_m">m</A>
+ -
+ <A HREF="#prindex_s">s</A>
+ -
+ <A HREF="#prindex_u">u</A>
+ -
+ <A HREF="#prindex_v">v</A>
+ <P>
+ <H2><A NAME="prindex_@">@</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX714">@command{!}</A>
+ <LI><A HREF="autoconf.html#IDX713">@command{.}</A>
+ <LI><A HREF="autoconf.html#IDX689">@command{/usr/xpg4/bin/sh} on Solaris</A>
+ <LI><A HREF="autoconf.html#IDX729">@command{:}</A>
+ <LI><A HREF="autoconf.html#IDX731">@command{awk}</A>
+ <LI><A HREF="autoconf.html#IDX715">@command{break}</A>
+ <LI><A HREF="autoconf.html#IDX716">@command{case}</A>
+ <LI><A HREF="autoconf.html#IDX732">@command{cat}</A>
+ <LI><A HREF="autoconf.html#IDX733">@command{cmp}</A>
+ <LI><A HREF="autoconf.html#IDX734">@command{cp}</A>
+ <LI><A HREF="autoconf.html#IDX735">@command{date}</A>
+ <LI><A HREF="autoconf.html#IDX736">@command{diff}</A>
+ <LI><A HREF="autoconf.html#IDX737">@command{dirname}</A>
+ <LI><A HREF="autoconf.html#IDX717">@command{echo}</A>
+ <LI><A HREF="autoconf.html#IDX738">@command{egrep}</A>
+ <LI><A HREF="autoconf.html#IDX718">@command{exit}</A>
+ <LI><A HREF="autoconf.html#IDX719">@command{export}</A>
+ <LI><A HREF="autoconf.html#IDX739">@command{expr}</A>, <A HREF="autoconf.html#IDX741">@command{expr}</A>
+ <LI><A HREF="autoconf.html#IDX740">@command{expr} (<SAMP>`|'</SAMP>)</A>
+ <LI><A HREF="autoconf.html#IDX720">@command{false}</A>
+ <LI><A HREF="autoconf.html#IDX721">@command{for}</A>
+ <LI><A HREF="autoconf.html#IDX742">@command{grep}</A>
+ <LI><A HREF="autoconf.html#IDX722">@command{if}</A>
+ <LI><A HREF="autoconf.html#IDX743">@command{ln}</A>
+ <LI><A HREF="autoconf.html#IDX745">@command{mv}</A>
+ <LI><A HREF="autoconf.html#IDX747">@command{sed}</A>
+ <LI><A HREF="autoconf.html#IDX748">@command{sed} (<SAMP>`t'</SAMP>)</A>
+ <LI><A HREF="autoconf.html#IDX723">@command{set}</A>
+ <LI><A HREF="autoconf.html#IDX724">@command{shift}</A>
+ <LI><A HREF="autoconf.html#IDX725">@command{source}</A>
+ <LI><A HREF="autoconf.html#IDX726">@command{test}</A>
+ <LI><A HREF="autoconf.html#IDX749">@command{touch}</A>
+ <LI><A HREF="autoconf.html#IDX727">@command{trap}</A>
+ <LI><A HREF="autoconf.html#IDX728">@command{true}</A>
+ <LI><A HREF="autoconf.html#IDX730">@command{unset}</A>
+ </DIR>
+ <H2><A NAME="prindex_a">a</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX221"><CODE>alloca</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_c">c</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX224"><CODE>chown</CODE></A>
+ <LI><A HREF="autoconf.html#IDX228"><CODE>closedir</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_e">e</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX231"><CODE>error_at_line</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_f">f</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX234"><CODE>fnmatch</CODE></A>
+ <LI><A HREF="autoconf.html#IDX241"><CODE>fork</CODE></A>
+ <LI><A HREF="autoconf.html#IDX246"><CODE>fseeko</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_g">g</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX250"><CODE>getgroups</CODE></A>
+ <LI><A HREF="autoconf.html#IDX266"><CODE>getloadavg</CODE></A>
+ <LI><A HREF="autoconf.html#IDX270"><CODE>getmntent</CODE></A>
+ <LI><A HREF="autoconf.html#IDX274"><CODE>getpgid</CODE></A>
+ <LI><A HREF="autoconf.html#IDX275"><CODE>getpgrp</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_l">l</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX279"><CODE>lstat</CODE></A>, <A HREF="autoconf.html#IDX316"><CODE>lstat</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_m">m</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX282"><CODE>malloc</CODE></A>
+ <LI><A HREF="autoconf.html#IDX286"><CODE>memcmp</CODE></A>
+ <LI><A HREF="autoconf.html#IDX290"><CODE>mktime</CODE></A>
+ <LI><A HREF="autoconf.html#IDX294"><CODE>mmap</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_s">s</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX304"><CODE>select</CODE></A>
+ <LI><A HREF="autoconf.html#IDX308"><CODE>setpgrp</CODE></A>
+ <LI><A HREF="autoconf.html#IDX320"><CODE>setvbuf</CODE></A>
+ <LI><A HREF="autoconf.html#IDX206"><CODE>snprintf</CODE></A>
+ <LI><A HREF="autoconf.html#IDX208"><CODE>sprintf</CODE></A>
+ <LI><A HREF="autoconf.html#IDX210"><CODE>sscanf</CODE></A>
+ <LI><A HREF="autoconf.html#IDX315"><CODE>stat</CODE></A>
+ <LI><A HREF="autoconf.html#IDX324"><CODE>strcoll</CODE></A>
+ <LI><A HREF="autoconf.html#IDX334"><CODE>strerror_r</CODE></A>
+ <LI><A HREF="autoconf.html#IDX338"><CODE>strftime</CODE></A>
+ <LI><A HREF="autoconf.html#IDX211"><CODE>strnlen</CODE></A>, <A HREF="autoconf.html#IDX342"><CODE>strnlen</CODE></A>
+ <LI><A HREF="autoconf.html#IDX328"><CODE>strtod</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_u">u</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX212"><CODE>unlink</CODE></A>
+ <LI><A HREF="autoconf.html#IDX346"><CODE>utime</CODE></A>
+ </DIR>
+ <H2><A NAME="prindex_v">v</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX213"><CODE>va_copy</CODE></A>
+ <LI><A HREF="autoconf.html#IDX214"><CODE>va_list</CODE></A>
+ <LI><A HREF="autoconf.html#IDX242"><CODE>vfork</CODE></A>
+ <LI><A HREF="autoconf.html#IDX351"><CODE>vprintf</CODE></A>
+ <LI><A HREF="autoconf.html#IDX207"><CODE>vsnprintf</CODE></A>
+ <LI><A HREF="autoconf.html#IDX209"><CODE>vsprintf</CODE></A>
+ </DIR>
+
+
+
+
+ <H2><A NAME="SEC191" HREF="autoconf_toc.html#TOC191">Concept Index</A></H2>
+
+ <P>
+ This is an alphabetical list of the files, tools, and concepts
+ introduced in this document.
+
+
+ <P>
+ Jump to:
+ <A HREF="#cindex_"">"</A>
+ -
+ <A HREF="#cindex_$">$</A>
+ -
+ <A HREF="#cindex_@">@</A>
+ -
+ <A HREF="#cindex_`">`</A>
+ -
+ <A HREF="#cindex_a">a</A>
+ -
+ <A HREF="#cindex_b">b</A>
+ -
+ <A HREF="#cindex_c">c</A>
+ -
+ <A HREF="#cindex_d">d</A>
+ -
+ <A HREF="#cindex_e">e</A>
+ -
+ <A HREF="#cindex_f">f</A>
+ -
+ <A HREF="#cindex_h">h</A>
+ -
+ <A HREF="#cindex_i">i</A>
+ -
+ <A HREF="#cindex_l">l</A>
+ -
+ <A HREF="#cindex_m">m</A>
+ -
+ <A HREF="#cindex_o">o</A>
+ -
+ <A HREF="#cindex_p">p</A>
+ -
+ <A HREF="#cindex_q">q</A>
+ -
+ <A HREF="#cindex_r">r</A>
+ -
+ <A HREF="#cindex_s">s</A>
+ -
+ <A HREF="#cindex_t">t</A>
+ -
+ <A HREF="#cindex_u">u</A>
+ -
+ <A HREF="#cindex_v">v</A>
+ -
+ <A HREF="#cindex_z">z</A>
+ <P>
+ <H2><A NAME="cindex_"">"</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX691"><SAMP>`"$@"'</SAMP></A>
+ </DIR>
+ <H2><A NAME="cindex_$">$</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX697">$(<VAR>commands</VAR>)</A>
+ <LI><A HREF="autoconf.html#IDX692">${<VAR>var</VAR>:-<VAR>value</VAR>}</A>
+ <LI><A HREF="autoconf.html#IDX694">${<VAR>var</VAR>=<VAR>expanded-value</VAR>}</A>
+ <LI><A HREF="autoconf.html#IDX693">${<VAR>var</VAR>=<VAR>literal</VAR>}</A>
+ </DIR>
+ <H2><A NAME="cindex_@">@</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX630"><SAMP>`@%:@'</SAMP></A>
+ <LI><A HREF="autoconf.html#IDX631"><SAMP>`@&t@'</SAMP></A>
+ <LI><A HREF="autoconf.html#IDX628"><SAMP>`@:>@'</SAMP></A>
+ <LI><A HREF="autoconf.html#IDX627"><SAMP>`@<:@'</SAMP></A>
+ <LI><A HREF="autoconf.html#IDX10">@command{autoconf}</A>
+ <LI><A HREF="autoconf.html#IDX126">@command{autoheader}</A>
+ <LI><A HREF="autoconf.html#IDX14">@command{autoreconf}</A>
+ <LI><A HREF="autoconf.html#IDX8">@command{autoscan}</A>
+ <LI><A HREF="autoconf.html#IDX806">@command{autoupdate}</A>
+ <LI><A HREF="autoconf.html#IDX790">@command{config.status}</A>
+ <LI><A HREF="autoconf.html#IDX752">@command{config.sub}</A>
+ <LI><A HREF="autoconf.html#IDX4">@command{configure}</A>, <A HREF="autoconf.html#IDX788">@command{configure}</A>
+ <LI><A HREF="autoconf.html#IDX9">@command{ifnames}</A>
+ <LI><A HREF="autoconf.html#IDX1016">@command{testsuite}</A>, <A HREF="autoconf.html#IDX1032">@command{testsuite}</A>
+ <LI><A HREF="autoconf.html#IDX629"><SAMP>`@S|@'</SAMP></A>
+ </DIR>
+ <H2><A NAME="cindex_`">`</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX695">`<VAR>commands</VAR>`</A>
+ </DIR>
+ <H2><A NAME="cindex_a">a</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX803"><TT>`acconfig.h'</TT></A>
+ <LI><A HREF="autoconf.html#IDX3"><TT>`aclocal.m4'</TT></A>
+ <LI><A HREF="autoconf.html#IDX686">Ash</A>
+ <LI><A HREF="autoconf.html#IDX636">Autom4te Library</A>
+ <LI><A HREF="autoconf.html#IDX635"><TT>`autom4te.cache'</TT></A>
+ <LI><A HREF="autoconf.html#IDX637"><TT>`autom4te.cfg'</TT></A>
+ <LI><A HREF="autoconf.html#IDX1">Automake</A>
+ <LI><A HREF="autoconf.html#IDX1015">Autotest</A>
+ <LI><A HREF="autoconf.html#IDX1033"><CODE>AUTOTEST_PATH</CODE></A>
+ </DIR>
+ <H2><A NAME="cindex_b">b</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX12">Back trace</A>, <A HREF="autoconf.html#IDX633">Back trace</A>
+ <LI><A HREF="autoconf.html#IDX687">Bash</A>
+ <LI><A HREF="autoconf.html#IDX688">Bash 2.05 and later</A>
+ </DIR>
+ <H2><A NAME="cindex_c">c</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX604">Cache</A>
+ <LI><A HREF="autoconf.html#IDX609">Cache variable</A>
+ <LI><A HREF="autoconf.html#IDX789">Cache, enabling</A>
+ <LI><A HREF="autoconf.html#IDX696">Command Substitution</A>
+ <LI><A HREF="autoconf.html#IDX120"><TT>`config.h'</TT></A>
+ <LI><A HREF="autoconf.html#IDX805"><TT>`config.h.bot'</TT></A>
+ <LI><A HREF="autoconf.html#IDX125"><TT>`config.h.in'</TT></A>
+ <LI><A HREF="autoconf.html#IDX804"><TT>`config.h.top'</TT></A>
+ <LI><A HREF="autoconf.html#IDX119">Configuration Header</A>
+ <LI><A HREF="autoconf.html#IDX124">Configuration Header Template</A>
+ <LI><A HREF="autoconf.html#IDX6"><TT>`configure.ac'</TT></A>
+ <LI><A HREF="autoconf.html#IDX5"><TT>`configure.in'</TT></A>
+ <LI><A HREF="autoconf.html#IDX37">Copyright Notice</A>
+ </DIR>
+ <H2><A NAME="cindex_d">d</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX399">Declaration, checking</A>
+ <LI><A HREF="autoconf.html#IDX670"><CODE>dnl</CODE></A>, <A HREF="autoconf.html#IDX685"><CODE>dnl</CODE></A>
+ </DIR>
+ <H2><A NAME="cindex_e">e</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX479">Endianness</A>
+ </DIR>
+ <H2><A NAME="cindex_f">f</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1035">FDL, GNU Free Documentation License</A>
+ <LI><A HREF="autoconf.html#IDX196">File, checking</A>
+ <LI><A HREF="autoconf.html#IDX215">Function, checking</A>
+ </DIR>
+ <H2><A NAME="cindex_h">h</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX367">Header, checking</A>
+ </DIR>
+ <H2><A NAME="cindex_i">i</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX156">Includes, default</A>
+ <LI><A HREF="autoconf.html#IDX47">Instantiation</A>
+ </DIR>
+ <H2><A NAME="cindex_l">l</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX584">Language</A>
+ <LI><A HREF="autoconf.html#IDX201">Library, checking</A>
+ <LI><A HREF="autoconf.html#IDX2">Libtool</A>
+ <LI><A HREF="autoconf.html#IDX148">Links</A>
+ </DIR>
+ <H2><A NAME="cindex_m">m</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX638">M4sugar</A>
+ <LI><A HREF="autoconf.html#IDX13">Macro invocation stack</A>, <A HREF="autoconf.html#IDX634">Macro invocation stack</A>
+ <LI><A HREF="autoconf.html#IDX671">Messages, from @command{autoconf}</A>
+ <LI><A HREF="autoconf.html#IDX614">Messages, from @command{configure}</A>
+ <LI><A HREF="autoconf.html#IDX746">Moving open files</A>
+ </DIR>
+ <H2><A NAME="cindex_o">o</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX298">obstack</A>
+ </DIR>
+ <H2><A NAME="cindex_p">p</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1034"><TT>`package.m4'</TT></A>
+ <LI><A HREF="autoconf.html#IDX556">POSIX termios headers</A>
+ <LI><A HREF="autoconf.html#IDX600">Previous Variable</A>
+ <LI><A HREF="autoconf.html#IDX157">Programs, checking</A>
+ </DIR>
+ <H2><A NAME="cindex_q">q</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX583">QNX 4.25</A>
+ <LI><A HREF="autoconf.html#IDX626">quadrigraphs</A>
+ <LI><A HREF="autoconf.html#IDX7">quotation</A>, <A HREF="autoconf.html#IDX625">quotation</A>
+ </DIR>
+ <H2><A NAME="cindex_r">r</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX40">Revision</A>
+ </DIR>
+ <H2><A NAME="cindex_s">s</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX408">Structure, checking</A>
+ <LI><A HREF="autoconf.html#IDX744">Symbolic links</A>
+ </DIR>
+ <H2><A NAME="cindex_t">t</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX557">termios POSIX headers</A>
+ <LI><A HREF="autoconf.html#IDX1017">test group</A>
+ </DIR>
+ <H2><A NAME="cindex_u">u</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX1014"><CODE>undefined macro: _m4_divert_diversion</CODE></A>
+ </DIR>
+ <H2><A NAME="cindex_v">v</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX601">Variable, Precious</A>
+ <LI><A HREF="autoconf.html#IDX34">Version</A>
+ <LI><A HREF="autoconf.html#IDX750"><CODE>VPATH</CODE></A>
+ </DIR>
+ <H2><A NAME="cindex_z">z</A></H2>
+ <DIR>
+ <LI><A HREF="autoconf.html#IDX690">Zsh</A>
+ </DIR>
+
+
+ <P><HR><P>
+ This document was generated on 10 July 2002 using
+ <A HREF="http://wwwinfo.cern.ch/dis/texi2html/">texi2html</A> 1.56k.
+ </BODY>
+ </HTML>
|
