From: Alexandre Duret-Lutz Date: Wed, 24 Sep 2003 20:54:46 +0000 (+0000) Subject: * doc/automake.texi: Refer to configure.ac instead of configure.in. X-Git-Tag: Release-1-7b~48 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=53249af3a637b7ac2f41955cd7a6c6e78d7a10d3;p=thirdparty%2Fautomake.git * doc/automake.texi: Refer to configure.ac instead of configure.in. --- diff --git a/ChangeLog b/ChangeLog index 1251cc031..4c62b5869 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,7 @@ 2003-09-24 Alexandre Duret-Lutz + * doc/automake.texi: Refer to configure.ac instead of configure.in. + * automake.texi: Move ... * doc/automake.texi: ... here. * doc/Makefile.am: New file. diff --git a/doc/automake.texi b/doc/automake.texi index b8a34bb36..71deb532a 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -149,10 +149,11 @@ should generally be one @file{Makefile.am} per directory of a project. 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} contents@footnote{Autoconf 2.50 promotes +the @file{configure.ac} contents@footnote{Older Autoconf versions used +@file{configure.in}. 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 @@ very particular. @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 @@ ad-hoc. You want to make them bulletproof, so you turn to Automake. @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 @@ autoconf 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, -@code{zardoz} has some Texinfo documentation. Your @file{configure.in} +@code{zardoz} 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 @@ Of course, GNU Hello is somewhat more featureful than your traditional two-liner. GNU Hello is internationalized, does option processing, and has a manual and a test suite. -@cindex configure.in, from GNU Hello -@cindex GNU Hello, configure.in -@cindex Hello, configure.in +@cindex configure.ac, from GNU Hello +@cindex GNU Hello, configure.ac +@cindex 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 @@ automake; they would be @file{false-true.o} and @file{true-true.o}. @node Invoking Automake @chapter Creating a @file{Makefile.in} -@cindex Multiple configure.in files +@cindex 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 -@file{Makefile.am} (by scanning @file{configure.in}; @pxref{configure}) +@file{Makefile.am} (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 -@file{configure.in}. (Alternatively, you may rely on Autoconf's +@file{configure.ac}. (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 @@ file. This feature is generally only used to automatically rebuild an 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 -@strong{scan} your @file{configure.in}, this won't build +@strong{scan} 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 @@ this purpose. @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 @@ probably should not be used. @item --no-force @opindex --no-force Ordinarily @code{automake} creates all @file{Makefile.in}s mentioned in -@file{configure.in}. This option causes it to only update those +@file{configure.ac}. 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 @@ for this reason. @node configure -@chapter Scanning @file{configure.in} +@chapter Scanning @file{configure.ac} -@cindex configure.in, scanning -@cindex Scanning configure.in +@cindex configure.ac, scanning +@cindex 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 @@ easier. These macros can automatically be put into your @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 @@ Files created by @code{AC_CONFIG_FILES} are removed by @code{make distclean}. @cindex Recognized macros by Automake Every time Automake is run it calls Autoconf to trace -@file{configure.in}. This way it can recognize the use of certain +@file{configure.ac}. 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 @@ Introduction, libtool, The Libtool Manual}). @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 @@ generated @file{Makefile.in}s. This macro defines the @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. -@code{m4_include} is seldom used by @file{configure.in} authors, but +@code{m4_include} 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 @@ Automake in certain situations. These macros must be defined in your @command{autoconf}. The @command{aclocal} program will automatically generate -@file{aclocal.m4} files based on the contents of @file{configure.in}. +@file{aclocal.m4} 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 @@ macros (@pxref{Local Macros}). 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 @@ macros installed at other places on the system. @section Autoconf macros supplied with Automake Automake ships with several Autoconf macros that you can use from your -@file{configure.in}. When you use one of them it will be included by +@file{configure.ac}. When you use one of them it will be included by @code{aclocal} in @file{aclocal.m4}. @menu @@ -1625,7 +1626,7 @@ obsolete because the @var{package} and @var{version} can be obtained 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 @@ AC_CONFIG_SRCDIR(src/foo.c) 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 @@ required macro. Macros not found locally will still be searched in system-wide directories, as explained in @ref{Macro search path}. Custom macros should be distributed for the same reason that -@file{configure.in} is: so that other people have all the sources of +@file{configure.ac} 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 @@ macro in the system-wide @command{aclocal} directory (@pxref{Extending 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 @@ nobase_dist_pkgdata_DATA = images/vortex.pgm 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 @@ hello_DEPENDENCIES = $(HELLO_SYSTEM) @noindent You can then setup the @code{$(HELLO_SYSTEM)} substitution from -@file{configure.in}: +@file{configure.ac}: @example @dots{} @@ -2454,7 +2455,7 @@ hello_SOURCES = hello-generic.c hello-common.c 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 @@ Building a static library is done by compiling all object files, then 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 -@code{AC_PROG_RANLIB} from your @file{configure.in} to define +@code{AC_PROG_RANLIB} 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 -@file{configure.in}, or by defining a per-library @code{maude_AR} +@file{configure.ac}, or by defining a per-library @code{maude_AR} variable (@pxref{Program and Library Variables}). @node A Shared Library @@ -3071,7 +3072,7 @@ program-specific linker flags (except for @samp{-l}, @samp{-L}, @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 @@ and we recommend avoiding it until you find it is required. Automake explicitly recognizes the use of @code{$(LIBOBJS)} and @code{$(ALLOCA)}, and uses this information, plus the list of -@code{LIBOBJS} files derived from @file{configure.in} to automatically +@code{LIBOBJS} 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 @@ The intermediate files generated by @code{yacc} (or @code{lex}) will be 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 @@ bin_PROGRAMS = foo 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 @@ more than one instance of @code{yacc} simultaneously. The @code{ylwrap} 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 @@ covered here, please report the new name so it can be added to the list. Automake includes full support for C++. Any package including C++ code must define the output variable -@samp{CXX} in @file{configure.in}; the simplest way to do this is to use +@samp{CXX} 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 @@ particular it must accept @samp{-c} and @samp{-o}. The value of @vindex CCASFLAGS You are required to set @code{CCAS} and @code{CCASFLAGS} via -@file{configure.in}. The autoconf macro @code{AM_PROG_AS} will do this +@file{configure.ac}. 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 @@ Only the suffixes @samp{.s} and @samp{.S} are recognized by Automake includes full support for Fortran 77. Any package including Fortran 77 code must define the output variable -@samp{F77} in @file{configure.in}; the simplest way to do this is to use +@samp{F77} 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 @@ If Automake detects that a program or shared library (as mentioned in 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 -@file{configure.in}, and that either @code{$(FLIBS)} +@file{configure.ac}, 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 @@ libfoo_la_LIBADD = $(FLIBS) @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 @@ Automake includes support for compiled Java, using @code{gcj}, the Java 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 @@ page for details. 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 -@file{configure.in} must call the macro @code{AM_C_PROTOTYPES} +@file{configure.ac} must call the macro @code{AM_C_PROTOTYPES} (@pxref{Macros}). @cvindex AM_C_PROTOTYPES @@ -3903,7 +3904,7 @@ extension. @code{EXEEXT} 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 @@ use in GNU programs, it tries hard to interoperate with other GNU tools. 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 -@code{lisp_LISP} is defined, then @file{configure.in} must run +@code{lisp_LISP} 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 @@ installation less nice for everybody else. @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 @@ Python source files are included in the distribution by default. 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 @@ hello_TEXINFOS = gpl.texi By default, Automake requires the file @file{texinfo.tex} to appear in the same directory as the Texinfo source. However, if you used -@code{AC_CONFIG_AUX_DIR} in @file{configure.in} (@pxref{Input, , Finding +@code{AC_CONFIG_AUX_DIR} 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 @@ or as the target of a @file{Makefile.am} rule). This list is printed by (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 -@code{include}) or in @file{configure.in} (using @code{m4_include}), and +@code{include}) 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 @@ Various features of Automake can be controlled by options in the 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 -@code{AM_INIT_AUTOMAKE} in @file{configure.in}. Currently understood +@code{AM_INIT_AUTOMAKE} in @file{configure.ac}. Currently understood options are: @vindex AUTOMAKE_OPTIONS @@ -5458,14 +5459,14 @@ These options behave exactly like their command-line counterpart (@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 @@ Automake supports a simple type of conditionals. @cvindex AM_CONDITIONAL Before using a conditional, you must define it by using -@code{AM_CONDITIONAL} in the @code{configure.in} file (@pxref{Macros}). +@code{AM_CONDITIONAL} 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 @@ will not work everywhere (for instance OS/2 does not have @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 -@file{configure.in} (@pxref{Particular Programs, , Particular Program +@file{configure.ac} (@pxref{Particular Programs, , Particular Program Checks, autoconf, The Autoconf Manual}) and use @code{$(LN_S)} in @file{Makefile.am}. @@ -6007,7 +6008,7 @@ all, this is what people expect from bug fix releases. 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 -@file{configure.in}: +@file{configure.ac}: @example AM_INIT_AUTOMAKE(1.6.1) dnl Require Automake 1.6.1 or better. @@ -6072,9 +6073,9 @@ or Info documentation, are usually distributed on similar grounds. Automake outputs rules in @file{Makefile}s to rebuild these files. For instance @command{make} will run @command{autoconf} to rebuild -@file{configure} whenever @file{configure.in} is changed. This makes +@file{configure} 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 @@ make sure that @command{make} notices sources files have been updated. 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 -@file{configure} was newer than @file{configure.in} when it was +@file{configure} 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 @@ project you work on uses different versions.) 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 diff --git a/doc/stamp-vti b/doc/stamp-vti index 85ab91b37..7f9e70470 100644 --- a/doc/stamp-vti +++ b/doc/stamp-vti @@ -1,4 +1,4 @@ -@set UPDATED 23 September 2003 +@set UPDATED 24 September 2003 @set UPDATED-MONTH September 2003 @set EDITION 1.7a @set VERSION 1.7a diff --git a/doc/version.texi b/doc/version.texi index 85ab91b37..7f9e70470 100644 --- a/doc/version.texi +++ b/doc/version.texi @@ -1,4 +1,4 @@ -@set UPDATED 23 September 2003 +@set UPDATED 24 September 2003 @set UPDATED-MONTH September 2003 @set EDITION 1.7a @set VERSION 1.7a