FYI: s/configure.in/configure.ac/ in doc/automake.texi

[Alexandre Duret-Lutz]

I'm checking this in.

2003-09-24  Alexandre Duret-Lutz  <address@hidden>

        * doc/automake.texi: Refer to configure.ac instead of configure.in.

Index: doc/automake.texi
===================================================================
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.1
diff -u -r1.1 automake.texi
--- doc/automake.texi   23 Sep 2003 22:39:11 -0000      1.1
+++ doc/automake.texi   24 Sep 2003 20:53:15 -0000
@@ -149,10 +149,11 @@
 Automake does constrain a project in certain ways; for instance it
 assumes that the project uses Autoconf (@pxref{Top, , Introduction,
 autoconf, The Autoconf Manual}), and enforces certain restrictions on
-the @file{configure.in} address@hidden 2.50 promotes
+the @file{configure.ac} address@hidden Autoconf versions used
address@hidden  Autoconf 2.50 and greater promotes
 @file{configure.ac} over @file{configure.in}.  The rest of this
-documentation will refer to @file{configure.in} as this use is not yet
-spread, but Automake supports @file{configure.ac} too.}.
+documentation will refer to @file{configure.ac}, but Automake also
+supports @file{configure.in} for backward compatibility.}.
 
 @cindex Automake requirements
 @cindex Requirements, Automake
@@ -234,7 +235,7 @@
 @cindex Overriding make variables
 
 Similarly, a variable defined in @file{Makefile.am} or @code{AC_SUBST}'ed
-from @file{configure.in} will override any definition of the variable that
+from @file{configure.ac} will override any definition of the variable that
 @code{automake} would ordinarily create.  This feature is more often
 useful than the ability to override a target definition.  Be warned that
 many of the variables generated by @code{automake} are considered to be for
@@ -605,7 +606,7 @@
 
 @cindex AM_INIT_AUTOMAKE, example use
 
-The first step is to update your @file{configure.in} to include the
+The first step is to update your @file{configure.ac} to include the
 commands that @code{automake} needs.  The way to do this is to add an
 @code{AM_INIT_AUTOMAKE} call just after @code{AC_INIT}:
 
@@ -642,7 +643,7 @@
 Now it is time to write your @file{Makefile.am} for @code{zardoz}.
 Since @code{zardoz} is a user program, you want to install it where the
 rest of the user programs go: @code{bindir}.  Additionally,
address@hidden has some Texinfo documentation.  Your @file{configure.in}
address@hidden has some Texinfo documentation.  Your @file{configure.ac}
 script uses @code{AC_REPLACE_FUNCS}, so you need to link against
 @samp{$(LIBOBJS)}.  So here's what you'd write:
 
@@ -676,11 +677,11 @@
 two-liner.  GNU Hello is internationalized, does option processing, and
 has a manual and a test suite.
 
address@hidden configure.in, from GNU Hello
address@hidden GNU Hello, configure.in
address@hidden Hello, configure.in
address@hidden configure.ac, from GNU Hello
address@hidden GNU Hello, configure.ac
address@hidden Hello, configure.ac
 
-Here is the @file{configure.in} from GNU Hello.
+Here is the @file{configure.ac} from GNU Hello.
 @strong{Please note:} The calls to @code{AC_INIT} and @code{AM_INIT_AUTOMAKE}
 in this example use a deprecated syntax.  For the current approach,
 see the description of @code{AM_INIT_AUTOMAKE} in @ref{Public macros}.
@@ -864,20 +865,20 @@
 @node Invoking Automake
 @chapter Creating a @file{Makefile.in}
 
address@hidden Multiple configure.in files
address@hidden Multiple configure.ac files
 @cindex Invoking Automake
 @cindex Automake, invoking
 
 To create all the @file{Makefile.in}s for a package, run the
 @code{automake} program in the top level directory, with no arguments.
 @code{automake} will automatically find each appropriate
address@hidden (by scanning @file{configure.in}; @pxref{configure})
address@hidden (by scanning @file{configure.ac}; @pxref{configure})
 and generate the corresponding @file{Makefile.in}.  Note that
 @code{automake} has a rather simplistic view of what constitutes a
-package; it assumes that a package has only one @file{configure.in}, at
-the top.  If your package has multiple @file{configure.in}s, then you
+package; it assumes that a package has only one @file{configure.ac}, at
+the top.  If your package has multiple @file{configure.ac}s, then you
 must run @code{automake} in each directory holding a
address@hidden  (Alternatively, you may rely on Autoconf's
address@hidden  (Alternatively, you may rely on Autoconf's
 @code{autoreconf}, which is able to recurse your package tree and run
 @code{automake} where appropriate.)
 
@@ -887,18 +888,18 @@
 out-of-date @file{Makefile.in}.  Note that @code{automake} must always
 be run from the topmost directory of a project, even if being used to
 regenerate the @file{Makefile.in} in some subdirectory.  This is
-necessary because @code{automake} must scan @file{configure.in}, and
+necessary because @code{automake} must scan @file{configure.ac}, and
 because @code{automake} uses the knowledge that a @file{Makefile.in} is
 in a subdirectory to change its behavior in some cases.
 
 @vindex AUTOCONF
-Automake will run @code{autoconf} to scan @file{configure.in} and its
+Automake will run @code{autoconf} to scan @file{configure.ac} and its
 dependencies (@file{aclocal.m4}), therefore @code{autoconf} must be in
 your @code{PATH}.  If there is an @code{AUTOCONF} variable in your
 environment it will be used instead of @code{autoconf}, this allows you
 to select a particular version of Autoconf.  By the way, don't
 misunderstand this paragraph: Automake runs @code{autoconf} to
address@hidden your @file{configure.in}, this won't build
address@hidden your @file{configure.ac}, this won't build
 @file{configure} and you still have to run @code{autoconf} yourself for
 this purpose.
 
@@ -918,7 +919,7 @@
 @opindex -a
 @opindex --add-missing
 Automake requires certain common files to exist in certain situations;
-for instance @file{config.guess} is required if @file{configure.in} runs
+for instance @file{config.guess} is required if @file{configure.ac} runs
 @code{AC_CANONICAL_HOST}.  Automake is distributed with several of these
 files (@pxref{Auxiliary Programs}); this option will cause the missing
 ones to be automatically added to the package, whenever possible.  In
@@ -992,7 +993,7 @@
 @item --no-force
 @opindex --no-force
 Ordinarily @code{automake} creates all @file{Makefile.in}s mentioned in
address@hidden  This option causes it to only update those
address@hidden  This option causes it to only update those
 @file{Makefile.in}s which are out of date with respect to one of their
 dependents.
 
@@ -1068,15 +1069,15 @@
 
 
 @node configure
address@hidden Scanning @file{configure.in}
address@hidden Scanning @file{configure.ac}
 
address@hidden configure.in, scanning
address@hidden Scanning configure.in
address@hidden configure.ac, scanning
address@hidden Scanning configure.ac
 
-Automake scans the package's @file{configure.in} to determine certain
+Automake scans the package's @file{configure.ac} to determine certain
 information about the package.  Some @code{autoconf} macros are required
-and some variables must be defined in @file{configure.in}.  Automake
-will also use information from @file{configure.in} to further tailor its
+and some variables must be defined in @file{configure.ac}.  Automake
+will also use information from @file{configure.ac} to further tailor its
 output.
 
 Automake also supplies some Autoconf macros to make the maintenance
@@ -1102,7 +1103,7 @@
 @cindex Automake requirements
 @cindex Requirements of Automake
 
-The one real requirement of Automake is that your @file{configure.in}
+The one real requirement of Automake is that your @file{configure.ac}
 call @code{AM_INIT_AUTOMAKE}.  This macro does several things which are
 required for proper Automake operation (@pxref{Macros}).
 @cvindex AM_INIT_AUTOMAKE
@@ -1139,7 +1140,7 @@
 @cindex Recognized macros by Automake
 
 Every time Automake is run it calls Autoconf to trace
address@hidden  This way it can recognize the use of certain
address@hidden  This way it can recognize the use of certain
 macros and tailor the generated @file{Makefile.in} appropriately.
 Currently recognized macros and their effects are:
 
@@ -1249,7 +1250,7 @@
 
 @item AC_PROG_YACC
 If a Yacc source file is seen, then you must either use this macro or
-define the variable @samp{YACC} in @file{configure.in}.  The former is
+define the variable @samp{YACC} in @file{configure.ac}.  The former is
 preferred (@pxref{Particular Programs, , Particular Program Checks,
 autoconf, The Autoconf Manual}).
 @cvindex AC_PROG_YACC
@@ -1297,11 +1298,11 @@
 
 @item m4_include
 @cvindex m4_include
-Files included by @file{configure.in} using this macro will be
+Files included by @file{configure.ac} using this macro will be
 detected by Automake and automatically distributed.  They will also
 appear as dependencies in @file{Makefile} rules.
 
address@hidden is seldom used by @file{configure.in} authors, but
address@hidden is seldom used by @file{configure.ac} authors, but
 can appear in @file{aclocal.m4} when @command{aclocal} detects that
 some required macros come from files local to your package (as
 opposed to macros installed in a system-wide directory, see
@@ -1323,7 +1324,7 @@
 @command{autoconf}.
 
 The @command{aclocal} program will automatically generate
address@hidden files based on the contents of @file{configure.in}.
address@hidden files based on the contents of @file{configure.ac}.
 This provides a convenient way to get Automake-provided macros,
 without having to search around.  The @command{aclocal} mechanism
 allows other packages to supply their own macros (@pxref{Extending
@@ -1332,7 +1333,7 @@
 
 At startup, @command{aclocal} scans all the @file{.m4} files it can
 find, looking for macro definitions (@pxref{Macro search path}).  Then
-it scans @file{configure.in}.  Any mention of one of the macros found
+it scans @file{configure.ac}.  Any mention of one of the macros found
 in the first step causes that macro, and any macros it in turn
 requires, to be put into @file{aclocal.m4}.
 
@@ -1567,7 +1568,7 @@
 @section Autoconf macros supplied with Automake
 
 Automake ships with several Autoconf macros that you can use from your
address@hidden  When you use one of them it will be included by
address@hidden  When you use one of them it will be included by
 @code{aclocal} in @file{aclocal.m4}.
 
 @menu
@@ -1625,7 +1626,7 @@
 from Autoconf's @code{AC_INIT} macro (which itself has an old and a new
 form).
 
-If your @file{configure.in} has:
+If your @file{configure.ac} has:
 @example
 AC_INIT(src/foo.c)
 AM_INIT_AUTOMAKE(mumble, 1.5)
@@ -1637,7 +1638,7 @@
 AM_INIT_AUTOMAKE
 @end example
 
-Note that if you're upgrading your @file{configure.in} from an earlier
+Note that if you're upgrading your @file{configure.ac} from an earlier
 version of Automake, it is not always correct to simply move the package
 and version arguments from @code{AM_INIT_AUTOMAKE} directly to
 @code{AC_INIT}, as in the example above.  The first argument to
@@ -1900,7 +1901,7 @@
 system-wide directories, as explained in @ref{Macro search path}.
 
 Custom macros should be distributed for the same reason that
address@hidden is: so that other people have all the sources of
address@hidden is: so that other people have all the sources of
 your package if they want to work on it.  Actually, this distribution
 happens automatically because all @code{m4_include}d files are
 distributed.
@@ -1911,7 +1912,7 @@
 aclocal}).  For instance Guile ships with a file called
 @file{guile.m4} that contains the macro @code{GUILE_FLAGS} which can
 be used to define setup compiler and linker flags appropriate for
-using Guile.  Using @code{GUILE_FLAGS} in @file{configure.in} will
+using Guile.  Using @code{GUILE_FLAGS} in @file{configure.ac} will
 cause @command{aclocal} to copy @file{guile.m4} into
 @file{aclocal.m4}, but as @file{guile.m4} is not part of the project,
 it will not be distributed.  Technically, that means a user which
@@ -2197,7 +2198,7 @@
 Automake generates rules to automatically rebuild @file{Makefile}s,
 @file{configure}, and other derived files like @file{Makefile.in}.
 
-If you are using @code{AM_MAINTAINER_MODE} in @file{configure.in}, then
+If you are using @code{AM_MAINTAINER_MODE} in @file{configure.ac}, then
 these automatic rebuilding rules are only enabled in maintainer mode.
 
 Sometimes you need to run @code{aclocal} with an argument like @code{-I}
@@ -2422,7 +2423,7 @@
 
 @noindent
 You can then setup the @code{$(HELLO_SYSTEM)} substitution from
address@hidden:
address@hidden:
 
 @example
 @dots{}
@@ -2454,7 +2455,7 @@
 endif
 @end example
 
-In this case, your @file{configure.in} should setup the @code{LINUX}
+In this case, your @file{configure.ac} should setup the @code{LINUX}
 conditional using @code{AM_CONDITIONAL} (@pxref{Conditionals}).
 
 When using conditionals like this you don't need to use the
@@ -2581,12 +2582,12 @@
 by invoking @code{$(AR) $(ARFLAGS)} followed by the name of the
 library and the list of objects, and finally by calling
 @code{$(RANLIB)} on that library.  You should call
address@hidden from your @file{configure.in} to define
address@hidden from your @file{configure.ac} to define
 @code{RANLIB} (Automake will complain otherwise).  @code{AR} and
 @code{ARFLAGS} default to @code{ar} and @code{cru} respectively; you
 can override these two variables my setting them in your
 @file{Makefile.am}, by @code{AC_SUBST}ing them from your
address@hidden, or by defining a per-library @code{maude_AR}
address@hidden, or by defining a per-library @code{maude_AR}
 variable (@pxref{Program and Library Variables}).
 
 @node A Shared Library
@@ -3071,7 +3072,7 @@
 @samp{-dlopen} and @samp{-dlpreopen}).  Use the @samp{_LDFLAGS} variable
 for this purpose.
 
-For instance, if your @file{configure.in} uses @code{AC_PATH_XTRA}, you
+For instance, if your @file{configure.ac} uses @code{AC_PATH_XTRA}, you
 could link your program against the X libraries like so:
 
 @example
@@ -3184,7 +3185,7 @@
 
 Automake explicitly recognizes the use of @code{$(LIBOBJS)} and
 @code{$(ALLOCA)}, and uses this information, plus the list of
address@hidden files derived from @file{configure.in} to automatically
address@hidden files derived from @file{configure.ac} to automatically
 include the appropriate source files in the distribution (@pxref{Dist}).
 These source files are also automatically handled in the
 dependency-tracking scheme; see @xref{Dependencies}.
@@ -3284,7 +3285,7 @@
 included in any distribution that is made.  That way the user doesn't
 need to have @code{yacc} or @code{lex}.
 
-If a @code{yacc} source file is seen, then your @file{configure.in} must
+If a @code{yacc} source file is seen, then your @file{configure.ac} must
 define the variable @samp{YACC}.  This is most easily done by invoking
 the macro @samp{AC_PROG_YACC} (@pxref{Particular Programs, , Particular
 Program Checks, autoconf, The Autoconf Manual}).
@@ -3310,7 +3311,7 @@
 foo_SOURCES = @dots{} parser.y @dots{}
 @end example
 
-If a @code{lex} source file is seen, then your @file{configure.in}
+If a @code{lex} source file is seen, then your @file{configure.ac}
 must define the variable @samp{LEX}.  You can use @samp{AC_PROG_LEX}
 to do this (@pxref{Particular Programs, , Particular Program Checks,
 autoconf, The Autoconf Manual}), but using @code{AM_PROG_LEX} macro
@@ -3339,7 +3340,7 @@
 program is distributed with Automake.  It should appear in the directory
 specified by @samp{AC_CONFIG_AUX_DIR} (@pxref{Input, , Finding
 `configure' Input, autoconf, The Autoconf Manual}), or the current
-directory if that macro is not used in @file{configure.in}.
+directory if that macro is not used in @file{configure.ac}.
 
 For @code{yacc}, simply managing locking is insufficient.  The output of
 @code{yacc} always uses the same symbol names internally, so it isn't
@@ -3404,7 +3405,7 @@
 Automake includes full support for C++.
 
 Any package including C++ code must define the output variable
address@hidden in @file{configure.in}; the simplest way to do this is to use
address@hidden in @file{configure.ac}; the simplest way to do this is to use
 the @code{AC_PROG_CXX} macro (@pxref{Particular Programs, , Particular
 Program Checks, autoconf, The Autoconf Manual}).
 
@@ -3442,7 +3443,7 @@
 @vindex CCASFLAGS
 
 You are required to set @code{CCAS} and @code{CCASFLAGS} via
address@hidden  The autoconf macro @code{AM_PROG_AS} will do this
address@hidden  The autoconf macro @code{AM_PROG_AS} will do this
 for you.  Unless they are already set, it simply sets @code{CCAS} to the
 C compiler and @code{CCASFLAGS} to the C compiler flags.
 
@@ -3460,7 +3461,7 @@
 Automake includes full support for Fortran 77.
 
 Any package including Fortran 77 code must define the output variable
address@hidden in @file{configure.in}; the simplest way to do this is to use
address@hidden in @file{configure.ac}; the simplest way to do this is to use
 the @code{AC_PROG_F77} macro (@pxref{Particular Programs, , Particular
 Program Checks, autoconf, The Autoconf Manual}).  @xref{Fortran 77 and
 Autoconf}.
@@ -3606,7 +3607,7 @@
 some @code{_PROGRAMS} or @code{_LTLIBRARIES} primary) contains source
 code that is a mixture of Fortran 77 and C and/or C++, then it requires
 that the macro @code{AC_F77_LIBRARY_LDFLAGS} be called in
address@hidden, and that either @code{$(FLIBS)}
address@hidden, and that either @code{$(FLIBS)}
 appear in the appropriate @code{_LDADD} (for programs) or @code{_LIBADD}
 (for shared libraries) variables.  It is the responsibility of the
 person writing the @file{Makefile.am} to make sure that @code{$(FLIBS)}
@@ -3629,7 +3630,7 @@
 @end example
 
 In this case, Automake will insist that @code{AC_F77_LIBRARY_LDFLAGS}
-is mentioned in @file{configure.in}.  Also, if @code{$(FLIBS)} hadn't
+is mentioned in @file{configure.ac}.  Also, if @code{$(FLIBS)} hadn't
 been mentioned in @code{foo_LDADD} and @code{libfoo_la_LIBADD}, then
 Automake would have issued a warning.
 
@@ -3713,8 +3714,8 @@
 front end to the GNU Compiler Collection.
 
 Any package including Java code to be compiled must define the output
-variable @samp{GCJ} in @file{configure.in}; the variable @samp{GCJFLAGS}
-must also be defined somehow (either in @file{configure.in} or
+variable @samp{GCJ} in @file{configure.ac}; the variable @samp{GCJFLAGS}
+must also be defined somehow (either in @file{configure.ac} or
 @file{Makefile.am}).  The simplest way to do this is to use the
 @code{AM_PROG_GCJ} macro.
 
@@ -3786,7 +3787,7 @@
 Support for de-ANSI-fication requires the source files @file{ansi2knr.c}
 and @file{ansi2knr.1} to be in the same package as the ANSI C source;
 these files are distributed with Automake.  Also, the package
address@hidden must call the macro @code{AM_C_PROTOTYPES}
address@hidden must call the macro @code{AM_C_PROTOTYPES}
 (@pxref{Macros}).
 @cvindex AM_C_PROTOTYPES
 
@@ -3903,7 +3904,7 @@
 
 However, Automake cannot apply this rewriting to @code{configure}
 substitutions.  This means that if you are conditionally building a
-program using such a substitution, then your @file{configure.in} must
+program using such a substitution, then your @file{configure.ac} must
 take care to add @samp{$(EXEEXT)} when constructing the output variable.
 
 With Autoconf 2.13 and earlier, you must explicitly use @code{AC_EXEEXT}
@@ -4334,7 +4335,7 @@
 Automake provides some support for Emacs Lisp.  The @samp{LISP} primary
 is used to hold a list of @file{.el} files.  Possible prefixes for this
 primary are @samp{lisp_} and @samp{noinst_}.  Note that if
address@hidden is defined, then @file{configure.in} must run
address@hidden is defined, then @file{configure.ac} must run
 @code{AM_PATH_LISPDIR} (@pxref{Macros}).
 
 Automake will byte-compile all Emacs Lisp source files using the Emacs
@@ -4357,7 +4358,7 @@
 @cindex Gettext support
 @cindex Support for GNU Gettext
 
-If @code{AM_GNU_GETTEXT} is seen in @file{configure.in}, then Automake
+If @code{AM_GNU_GETTEXT} is seen in @file{configure.ac}, then Automake
 turns on support for GNU gettext, a message catalog system for
 internationalization
 (@pxref{GNU Gettext, , , gettext, GNU gettext utilities}).
@@ -4454,7 +4455,7 @@
 
 Automake ships with an Autoconf macro called @code{AM_PATH_PYTHON} which
 will determine some Python-related directory variables (see below).  If
-you have called @code{AM_PATH_PYTHON} from @file{configure.in}, then you
+you have called @code{AM_PATH_PYTHON} from @file{configure.ac}, then you
 may use the following variables to list you Python source files in your
 variables: @samp{python_PYTHON}, @samp{pkgpython_PYTHON},
 @samp{pyexecdir_PYTHON}, @samp{pkgpyexecdir_PYTHON}, depending where you
@@ -4652,7 +4653,7 @@
 
 By default, Automake requires the file @file{texinfo.tex} to appear in
 the same directory as the Texinfo source.  However, if you used
address@hidden in @file{configure.in} (@pxref{Input, , Finding
address@hidden in @file{configure.ac} (@pxref{Input, , Finding
 `configure' Input, autoconf, The Autoconf Manual}), then
 @file{texinfo.tex} is looked for there.  Automake supplies
 @file{texinfo.tex} if @samp{--add-missing} is given.
@@ -4962,7 +4963,7 @@
 (i.e. the source files corresponding to the files specified in various
 Autoconf macros such as @code{AC_CONFIG_FILES} and siblings) are
 automatically distributed.  Files included in @file{Makefile.am}s (using
address@hidden) or in @file{configure.in} (using @code{m4_include}), and
address@hidden) or in @file{configure.ac} (using @code{m4_include}), and
 helper scripts installed with @samp{automake --add-missing} are also
 distributed.
 
@@ -5293,7 +5294,7 @@
 basis when listed in a special @file{Makefile} variable named
 @code{AUTOMAKE_OPTIONS}.  They are applied globally to all processed
 @file{Makefiles} when listed in the first argument of
address@hidden in @file{configure.in}.  Currently understood
address@hidden in @file{configure.ac}.  Currently understood
 options are:
 @vindex AUTOMAKE_OPTIONS
 
@@ -5458,14 +5459,14 @@
 (@pxref{Invoking Automake}).  This allows you to enable or disable some
 warning categories on a per-file basis.  You can also setup some warnings
 for your entire project; for instance try @code{AM_INIT_AUTOMAKE([-Wall])}
-in your @file{configure.in}.
+in your @file{configure.ac}.
 
 @end table
 
 Unrecognized options are diagnosed by @code{automake}.
 
 If you want an option to apply to all the files in the tree, you can use
-the @code{AM_INIT_AUTOMAKE} macro in @file{configure.in}.
+the @code{AM_INIT_AUTOMAKE} macro in @file{configure.ac}.
 @xref{Macros}.
 
 
@@ -5644,7 +5645,7 @@
 
 @cvindex AM_CONDITIONAL
 Before using a conditional, you must define it by using
address@hidden in the @code{configure.in} file (@pxref{Macros}).
address@hidden in the @code{configure.ac} file (@pxref{Macros}).
 
 @defmac AM_CONDITIONAL (@var{conditional}, @var{condition})
 The conditional name, @var{conditional}, should be a simple string
@@ -5939,7 +5940,7 @@
 @command{ln}).  Ideally you should fall back to @code{cp -p} when
 @code{ln} does not work.  An easy way, if symbolic links are
 acceptable to you, is to add @code{AC_PROG_LN_S} to
address@hidden (@pxref{Particular Programs, , Particular Program
address@hidden (@pxref{Particular Programs, , Particular Program
 Checks, autoconf, The Autoconf Manual}) and use @code{$(LN_S)} in
 @file{Makefile.am}.
 
@@ -6007,7 +6008,7 @@
 Note that if your package relies on a feature or a bug fix introduced in
 a release, you can pass this version as an option to Automake to ensure
 older releases will not be used.  For instance, use this in your
address@hidden:
address@hidden:
 
 @example
   AM_INIT_AUTOMAKE(1.6.1)    dnl Require Automake 1.6.1 or better.
@@ -6072,9 +6073,9 @@
 
 Automake outputs rules in @file{Makefile}s to rebuild these files.  For
 instance @command{make} will run @command{autoconf} to rebuild
address@hidden whenever @file{configure.in} is changed.  This makes
address@hidden whenever @file{configure.ac} is changed.  This makes
 development safer by ensuring a @file{configure} is never out-of-date
-with respect to @file{configure.in}.
+with respect to @file{configure.ac}.
 
 As generated files shipped in packages are up-to-date, and because
 @command{tar} preserves times-tamps, these rebuild rules are not
@@ -6097,9 +6098,9 @@
 
 This times tamp shift is troublesome when both sources and generated
 files are kept under CVS.  Because CVS processes files in alphabetical
-order, @file{configure.in} will appear older than @file{configure}
+order, @file{configure.ac} will appear older than @file{configure}
 after a @command{cvs update} that updates both files, even if
address@hidden was newer than @file{configure.in} when it was
address@hidden was newer than @file{configure.ac} when it was
 checked in.  Calling @code{make} will then trigger a spurious rebuild
 of @file{configure}.
 
@@ -6153,7 +6154,7 @@
 Or people use a script to fix the timestamp after a checkout (the GCC
 folks have such a script).
 @item
-Or @file{configure.in} uses @code{AM_MAINTAINER_MODE}, which will
+Or @file{configure.ac} uses @code{AM_MAINTAINER_MODE}, which will
 disable all these rebuild rules by default.  This is further discussed
 in @ref{maintainer-mode}.
 @end itemize
-- 
Alexandre Duret-Lutz