autoconf.texi

这是一个自动生成MAKEFILE的工具。在LINUX工程项目里是很好的帮手。希望对大家有点帮助。

needs to be processed by @code{configure} in order to be used.
@end defvar

@defvar datadir
@ovindex datadir
The directory for installing read-only architecture-independent data.
@end defvar

@defvar exec_prefix
@ovindex exec_prefix
The installation prefix for architecture-dependent files.
@end defvar

@defvar includedir
@ovindex includedir
The directory for installing C header files.
@end defvar

@defvar infodir
@ovindex infodir
The directory for installing documentation in Info format.
@end defvar

@defvar libdir
@ovindex libdir
The directory for installing object code libraries.
@end defvar

@defvar libexecdir
@ovindex libexecdir
The directory for installing executables that other programs run.
@end defvar

@defvar localstatedir
@ovindex localstatedir
The directory for installing modifiable single-machine data.
@end defvar

@defvar mandir
@ovindex mandir
The top-level directory for installing documentation in man format.
@end defvar

@defvar oldincludedir
@ovindex oldincludedir
The directory for installing C header files for non-gcc compilers.
@end defvar

@defvar prefix
@ovindex prefix
The installation prefix for architecture-independent files.
@end defvar

@defvar sbindir
@ovindex sbindir
The directory for installing executables that system
administrators run.
@end defvar

@defvar sharedstatedir
@ovindex sharedstatedir
The directory for installing modifiable architecture-independent data.
@end defvar

@defvar srcdir
@ovindex srcdir
The directory that contains the source code for that @file{Makefile}.
@end defvar

@defvar sysconfdir
@ovindex sysconfdir
The directory for installing read-only single-machine data.
@end defvar

@defvar top_srcdir
@ovindex top_srcdir
The top-level source code directory for the package.  In the top-level
directory, this is the same as @code{srcdir}.
@end defvar

@defvar CFLAGS
@ovindex CFLAGS
Debugging and optimization options for the C compiler.  If it is not set
in the environment when @code{configure} runs, the default value is set
when you call @code{AC_PROG_CC} (or empty if you don't).  @code{configure}
uses this variable when compiling programs to test for C features.
@end defvar

@defvar CPPFLAGS
@ovindex CPPFLAGS
Header file search directory (@samp{-I@var{dir}}) and any other
miscellaneous options for the C preprocessor and compiler.  If it is not
set in the environment when @code{configure} runs, the default value is
empty.  @code{configure} uses this variable when compiling or
preprocessing programs to test for C features.
@end defvar

@defvar CXXFLAGS
@ovindex CXXFLAGS
Debugging and optimization options for the C++ compiler.  If it is not
set in the environment when @code{configure} runs, the default value is
set when you call @code{AC_PROG_CXX} (or empty if you don't).
@code{configure} uses this variable when compiling programs to test for
C++ features.
@end defvar

@defvar FFLAGS
@ovindex FFLAGS
Debugging and optimization options for the Fortran 77 compiler.  If it
is not set in the environment when @code{configure} runs, the default
value is set when you call @code{AC_PROG_F77} (or empty if you don't).
@code{configure} uses this variable when compiling programs to test for
Fortran 77 features.
@end defvar

@defvar DEFS
@ovindex DEFS
@samp{-D} options to pass to the C compiler.  If @code{AC_CONFIG_HEADER}
is called, @code{configure} replaces @samp{@@DEFS@@} with
@samp{-DHAVE_CONFIG_H} instead (@pxref{Configuration Headers}).  This
variable is not defined while @code{configure} is performing its tests,
only when creating the output files.  @xref{Setting Output Variables}, for
how to check the results of previous tests.
@end defvar

@defvar LDFLAGS
@ovindex LDFLAGS
Stripping (@samp{-s}) and any other miscellaneous options for the
linker.  If it is not set in the environment when @code{configure} runs,
the default value is empty.  @code{configure} uses this variable when
linking programs to test for C features.
@end defvar

@defvar LIBS
@ovindex LIBS
@samp{-l} and @samp{-L} options to pass to the linker.
@end defvar

@node Build Directories, Automatic Remaking, Preset Output Variables, Makefile Substitutions
@subsection Build Directories

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.

To support doing this, @code{make} uses the @code{VPATH} variable to
find the files that are in the source directory.  GNU @code{make} and
most other recent @code{make} programs can do this.  Older @code{make}
programs do not support @code{VPATH}; when using them, the source code
must be in the same directory as the object files.

To support @code{VPATH}, each @file{Makefile.in} should contain two
lines that look like:

@example
srcdir = @@srcdir@@
VPATH = @@srcdir@@
@end example

Do not set @code{VPATH} to the value of another variable, for example
@samp{VPATH = $(srcdir)}, because some versions of @code{make} do not do
variable substitutions on the value of @code{VPATH}.

@code{configure} substitutes in the correct value for @code{srcdir} when
it produces @file{Makefile}.

Do not use the @code{make} variable @code{$<}, which expands to the
pathname of the file in the source directory (found with @code{VPATH}),
except in implicit rules.  (An implicit rule is one such as @samp{.c.o},
which tells how to create a @file{.o} file from a @file{.c} file.)  Some
versions of @code{make} do not set @code{$<} in explicit rules; they
expand it to an empty value.

Instead, @file{Makefile} command lines should always refer to source
files by prefixing them with @samp{$(srcdir)/}.  For example:

@example
time.info: time.texinfo
        $(MAKEINFO) $(srcdir)/time.texinfo
@end example

@node Automatic Remaking,  , Build Directories, Makefile Substitutions
@subsection Automatic Remaking

You can put rules like the following in the top-level @file{Makefile.in}
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 @file{aclocal.m4} and those related to
configuration header files.  Omit from the @file{Makefile.in} rules any
of these files that your package does not use.

The @samp{$@{srcdir@}/} prefix is included because of limitations in the
@code{VPATH} mechanism.

The @file{stamp-} files are necessary because the timestamps of
@file{config.h.in} and @file{config.h} will not be changed if remaking
them does not change their contents.  This feature avoids unnecessary
recompilation.  You should include the file @file{stamp-h.in} your
package's distribution, so @code{make} will consider @file{config.h.in}
up to date.  On some old BSD systems, @code{touch} or any command that
results in an empty file does not update the timestamps, so use a
command like @code{echo} as a workaround.
@c Using @code{date} would cause needless CVS conflicts.

@example
@group
$@{srcdir@}/configure: configure.in aclocal.m4
        cd $@{srcdir@} && autoconf

# autoheader might not change config.h.in, so touch a stamp file.
$@{srcdir@}/config.h.in: stamp-h.in
$@{srcdir@}/stamp-h.in: configure.in aclocal.m4 acconfig.h \
    config.h.top config.h.bot
        cd $@{srcdir@} && autoheader
        echo timestamp > $@{srcdir@}/stamp-h.in

config.h: stamp-h
stamp-h: config.h.in config.status
        ./config.status

Makefile: Makefile.in config.status
        ./config.status

config.status: configure
        ./config.status --recheck
@end group
@end example

In addition, you should pass @samp{echo timestamp > stamp-h} in the
@var{extra-cmds} argument to @code{AC_OUTPUT}, so @file{config.status}
will ensure that @file{config.h} is considered up to date.
@xref{Output}, for more information about @code{AC_OUTPUT}.

@xref{Invoking config.status}, for more examples of handling
configuration-related dependencies.

@node Configuration Headers, Subdirectories, Makefile Substitutions, Setup
@section Configuration Header Files

When a package tests more than a few C preprocessor symbols, the command
lines to pass @samp{-D} options to the compiler can get quite long.
This causes two problems.  One is that the @code{make} 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 @samp{-D} options to the compiler, @code{configure} scripts can
create a C header file containing @samp{#define} directives.  The
@code{AC_CONFIG_HEADER} macro selects this kind of output.  It should be
called right after @code{AC_INIT}.

The package should @samp{#include} the configuration header file before
any other header files, to prevent inconsistencies in declarations (for
example, if it redefines @code{const}).  Use @samp{#include <config.h>}
instead of @samp{#include "config.h"}, and pass the C compiler a
@samp{-I.} option (or @samp{-I..}; whichever directory contains
@file{config.h}).  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 @file{config.h} from the source
directory.

@defmac AC_CONFIG_HEADER (@var{header-to-create} @dots{})
@maindex CONFIG_HEADER
@cvindex HAVE_CONFIG_H
Make @code{AC_OUTPUT} create the file(s) in the whitespace-separated
list @var{header-to-create} containing C preprocessor @code{#define}
statements, and replace @samp{@@DEFS@@} in generated files with
@samp{-DHAVE_CONFIG_H} instead of the value of @code{DEFS}.  The usual
name for @var{header-to-create} is @file{config.h}.

If @var{header-to-create} already exists and its contents are identical
to what @code{AC_OUTPUT} 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.

Usually the input file is named @file{@var{header-to-create}.in};
however, you can override the input file name by appending to
@var{header-to-create}, a colon-separated list of input files.
Examples:
@example
AC_CONFIG_HEADER(defines.h:defines.hin)
AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post)
@end example
@noindent
Doing this allows you to keep your file names acceptable to MS-DOS, or
to prepend and/or append boilerplate to the file.
@end defmac

@menu
* Header Templates::            Input for the configuration headers.
* Invoking autoheader::         How to create configuration templates.
@end menu

@node Header Templates, Invoking autoheader, Configuration Headers, Configuration Headers
@subsection Configuration Header Templates

Your distribution should contain a template file that looks as you want
the final header file to look, including comments, with default values
in the @code{#define} statements.  For example, suppose your
@file{configure.in} makes these calls:

@example
AC_CONFIG_HEADER(conf.h)
AC_CHECK_HEADERS(unistd.h)
@end example

@noindent
Then you could have code like the following in @file{conf.h.in}.
On systems that have @file{unistd.h}, @code{configure} will change the 0
to a 1.  On other systems, it will leave the line unchanged.

@example
@group
/* Define as 1 if you have unistd.h.  */
#define HAVE_UNISTD_H 0
@end group
@end example