autoconf.texi

autoconf 2.59版,可用于redhat系统.用于编译原码,编写makefile文件.

argument:

@example
echo "Hard rock was here!  --[AC_DC]"
@end example

@noindent
which will result in

@example
echo "Hard rock was here!  --AC_DC"
@end example

@noindent
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 @emph{use double
quoting for all literal string arguments}:

@example
AC_MSG_WARN([[AC_DC stinks  --Iron Maiden]])
@end example

You are now able to understand one of the constructs of Autoconf that
has been continually misunderstood@dots{}  The rule of thumb is that
@emph{whenever you expect macro expansion, expect quote expansion};
i.e., expect one level of quotes to be lost.  For instance:

@example
AC_COMPILE_IFELSE([char b[10];],, [AC_MSG_ERROR([you lose])])
@end example

@noindent
is incorrect: here, the first argument of @code{AC_COMPILE_IFELSE} is
@samp{char b[10];} and will be expanded once, which results in
@samp{char b10;}.  (There was an idiom common in Autoconf's past to
address this issue via the M4 @code{changequote} 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:

@example
AC_COMPILE_IFELSE([[char b[10];]],, [AC_MSG_ERROR([you lose])])
@end example

@noindent
Voil@`a, you actually produce @samp{char b[10];} this time!

The careful reader will notice that, according to these guidelines, the
``properly'' quoted @code{AC_CHECK_HEADER} 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.

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{[]} to make the emptiness of the
argument explicit, or you may simply omit the trailing commas.  The
three lines below are equivalent:

@example
AC_CHECK_HEADERS(stdio.h, [], [], [])
AC_CHECK_HEADERS(stdio.h,,,)
AC_CHECK_HEADERS(stdio.h)
@end example

It is best to put each macro call on its own line in
@file{configure.ac}.  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.

You can include comments in @file{configure.ac} files by starting them
with the @samp{#}.  For example, it is helpful to begin
@file{configure.ac} files with a line like this:

@example
# Process this file with autoconf to produce a configure script.
@end example

@node configure.ac Layout
@subsection Standard @file{configure.ac} Layout

The order in which @file{configure.ac} calls the Autoconf macros is not
important, with a few exceptions.  Every @file{configure.ac} must
contain a call to @code{AC_INIT} before the checks, and a call to
@code{AC_OUTPUT} at the end (@pxref{Output}).  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 (@pxref{Existing
Tests}), and they also warn you when @command{configure} is created if they
are called out of order.

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.

@display
@group
Autoconf requirements
@code{AC_INIT(@var{package}, @var{version}, @var{bug-report-address})}
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(@r{[}@var{file@dots{}}@r{]})}
@code{AC_OUTPUT}
@end group
@end display


@node autoscan Invocation
@section Using @command{autoscan} to Create @file{configure.ac}
@cindex @command{autoscan}

The @command{autoscan} program can help you create and/or maintain a
@file{configure.ac} 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 @file{configure.scan} which is a preliminary @file{configure.ac}
for that package, and checks a possibly existing @file{configure.ac} for
completeness.

When using @command{autoscan} to create a @file{configure.ac}, you
should manually examine @file{configure.scan} before renaming it to
@file{configure.ac}; 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} (@pxref{Configuration Headers}).  You might
also have to change or add some @code{#if} directives to your program in
order to make it work with Autoconf (@pxref{ifnames Invocation}, for
information about a program that can help with that job).

When using @command{autoscan} to maintain a @file{configure.ac}, simply
consider adding its suggestions.  The file @file{autoscan.log} will
contain detailed information on why a macro is requested.

@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{#} are
comments.

@command{autoscan} accepts the following options:

@table @option
@item --help
@itemx -h
Print a summary of the command line options and exit.

@item --version
@itemx -V
Print the version number of Autoconf and exit.

@item --verbose
@itemx -v
Print the names of the files it examines and the potentially interesting
symbols it finds in them.  This output can be voluminous.

@item --include=@var{dir}
@itemx -I @var{dir}
Append @var{dir} to the include path.  Multiple invocations accumulate.

@item --prepend-include=@var{dir}
@item -B @var{dir}
Prepend @var{dir} to the include path.  Multiple invocations accumulate.
@end table

@node ifnames Invocation
@section Using @command{ifnames} to List Conditionals
@cindex @command{ifnames}

@command{ifnames} can help you write @file{configure.ac} 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
@file{configure.ac} generated by @command{autoscan} (@pxref{autoscan
Invocation}).

@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{#elif}, @code{#ifdef}, or @code{#ifndef}
directives.  It prints each identifier on a line, followed by a
space-separated list of the files in which that identifier occurs.

@noindent
@command{ifnames} accepts the following options:

@table @option
@item --help
@itemx -h
Print a summary of the command line options and exit.

@item --version
@itemx -V
Print the version number of Autoconf and exit.
@end table

@node autoconf Invocation
@section Using @command{autoconf} to Create @command{configure}
@cindex @command{autoconf}

To create @command{configure} from @file{configure.ac}, run the
@command{autoconf} program with no arguments.  @command{autoconf} processes
@file{configure.ac} with the M4 macro processor, using the
Autoconf macros.  If you give @command{autoconf} an argument, it reads that
file instead of @file{configure.ac} 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 @file{configure.ac} and writes the configuration script
to the standard output.

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 @file{acsite.m4} in the directory that
contains the distributed Autoconf macro files, and for the optional file
@file{aclocal.m4} in the current directory.  Those files can contain
your site's or the package's own Autoconf macro definitions
(@pxref{Writing Autoconf Macros}, 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.

@command{autoconf} accepts the following options:

@table @option
@item --help
@itemx -h
Print a summary of the command line options and exit.

@item --version
@itemx -V
Print the version number of Autoconf and exit.

@item --verbose
@itemx -v
Report processing steps.

@item --debug
@itemx -d
Don't remove the temporary files.

@item --force
@itemx -f
Remake @file{configure} even if newer than its input files.

@item --include=@var{dir}
@itemx -I @var{dir}
Append @var{dir} to the include path.  Multiple invocations accumulate.

@item --prepend-include=@var{dir}
@item -B @var{dir}
Prepend @var{dir} to the include path.  Multiple invocations accumulate.

@item --output=@var{file}
@itemx -o @var{file}
Save output (script or trace) to @var{file}.  The file @option{-} stands
for the standard output.

@item --warnings=@var{category}
@itemx -W @var{category}
@evindex WARNINGS
Report the warnings related to @var{category} (which can actually be a
comma separated list).  @xref{Reporting Messages}, macro
@code{AC_DIAGNOSE}, for a comprehensive list of categories.  Special
values include:

@table @samp
@item all
report all the warnings

@item none
report none

@item error
treats warnings as errors

@item no-@var{category}
disable warnings falling into @var{category}
@end table

Warnings about @samp{syntax} are enabled by default, and the environment
variable @code{WARNINGS}, a comma separated list of categories, is
honored.  Passing @samp{-W @var{category}} will actually behave as if
you had passed @samp{--warnings=syntax,$WARNINGS,@var{category}}.  If
you want to disable the defaults and @code{WARNINGS}, but (for example)
enable the warnings about obsolete constructs, you would use @option{-W
none,obsolete}.

@cindex Back trace
@cindex Macro invocation stack
Because @command{autoconf} uses @command{autom4te} behind the scenes, it
displays a back trace for errors, but not for warnings; if you want
them, just pass @option{-W error}.  @xref{autom4te Invocation}, for some
examples.

@item --trace=@var{macro}[:@var{format}]
@itemx -t @var{macro}[:@var{format}]
Do not create the @command{configure} script, but list the calls to
@var{macro} according to the @var{format}.  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} as long as needed.

The @var{format} is a regular string, with newlines if desired, and
several special escape codes.  It defaults to @samp{$f:$l:$n:$%}; see
@ref{autom4te Invocation}, for details on the @var{format}.

@item --initialization
@itemx -i
By default, @option{--trace} does not trace the initialization of the
Autoconf macros (typically the @code{AC_DEFUN} definitions).  This
results in a noticeable speedup, but can be disabled by this option.
@end table


It is often necessary to check the content of a @file{configure.ac}
file, but parsing it yourself is extremely fragile and error-prone.  It
is suggested that you rely upon @option{--trace} to scan
@file{configure.ac}.  For instance, to find the list of variables that
are substituted, use:

@example
@group
$ @kbd{autoconf -t AC_SUBST}
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}
@end group
@end example

@noindent
The example below highlights the difference between @samp{$@@},