@value{UPDATED}), a program that creates GNU standards-compliant
Makefiles from template files.
-Copyright @copyright{} 1995-2012 Free Software Foundation, Inc.
+Copyright @copyright{} 1995-2013 Free Software Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
@author David MacKenzie
@author Tom Tromey
@author Alexandre Duret-Lutz
+@author Ralf Wildenhues
+@author Stefano Lattarini
@page
@vskip 0pt plus 1filll
@insertcopying
Simple Tests
* Scripts-based Testsuites:: Automake-specific concepts and terminology
-* Serial Test Harness:: Older (and obsolescent) serial test harness
+* Serial Test Harness:: Older (and discouraged) serial test harness
* Parallel Test Harness:: Generic concurrent test harness
Using the TAP test protocol
maintainers).
The typical Automake input file is simply a series of variable definitions.
-Each such file is processed to create a @file{Makefile.in}. There
-should generally be one @file{Makefile.am} per directory of a project.
+Each such file is processed to create a @file{Makefile.in}.
@cindex Constraints of Automake
@cindex Automake constraints
that is then used by the automatic dependency tracking feature
(@pxref{Dependencies}).
-@item elisp-comp
-This program is used to byte-compile Emacs Lisp code.
-
@item install-sh
This is a replacement for the @command{install} program that works on
platforms where @command{install} is unavailable or unusable.
instance, @option{-Wno-syntax} will hide the warnings about unused
variables.
-The categories output by default are @samp{syntax} and
+The categories output by default are @samp{obsolete}, @samp{syntax} and
@samp{unsupported}. Additionally, @samp{gnu} and @samp{portability}
are enabled in @option{--gnu} and @option{--gnits} strictness.
@file{config.guess},
@file{config.sub},
@file{depcomp},
-@file{elisp-comp},
@file{compile},
@file{install-sh},
@file{ltmain.sh},
macro.
@item AC_CONFIG_HEADERS
-Automake will generate rules to rebuild these headers. Older versions
-of Automake required the use of @code{AM_CONFIG_HEADER}; this is no
-longer the case, and that macro has indeed been removed.
+Automake will generate rules to rebuild these headers from the
+corresponding templates (usually, the template for a @file{foo.h}
+header being @file{foo.h.in}). Older versions of Automake
+required the use of @code{AM_CONFIG_HEADER}; this is no longer
+the case, and that macro has indeed been removed.
As with @code{AC_CONFIG_FILES} (@pxref{Requirements}), parts of the
specification using shell variables will be ignored as far as
numerous macros, it will rapidly become difficult to maintain, and it
will be almost impossible to share macros between packages.
-@vindex ACLOCAL_AMFLAGS
The second possibility, which we do recommend, is to write each macro
-in its own file and gather all of these files in a directory. This
-directory is usually called @file{m4/}. To build @file{aclocal.m4},
-one should therefore instruct @command{aclocal} to scan @file{m4/}.
-From the command line, this is done with @samp{aclocal -I m4}. The
-top-level @file{Makefile.am} should also be updated to define
-
-@example
-ACLOCAL_AMFLAGS = -I m4
-@end example
-
-@code{ACLOCAL_AMFLAGS} contains options to pass to @command{aclocal}
-when @file{aclocal.m4} is to be rebuilt by @command{make}. This line is
-also used by @command{autoreconf} (@pxref{autoreconf Invocation, ,
-Using @command{autoreconf} to Update @file{configure} Scripts,
-autoconf, The Autoconf Manual}) to run @command{aclocal} with suitable
-options, or by @command{autopoint} (@pxref{autopoint Invocation, ,
-Invoking the @command{autopoint} Program, gettext, GNU gettext tools})
-and @command{gettextize} (@pxref{gettextize Invocation, , Invoking the
-@command{gettextize} Program, gettext, GNU gettext tools}) to locate
-the place where Gettext's macros should be installed. So even if you
-do not really care about the rebuild rules, you should define
-@code{ACLOCAL_AMFLAGS}.
-
-When @samp{aclocal -I m4} is run, it will build an @file{aclocal.m4}
+in its own file and gather all these files in a directory. This
+directory is usually called @file{m4/}. Then it's enough to update
+@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_DIRS}:
+
+@example
+AC_CONFIG_MACRO_DIRS([m4])
+@end example
+
+@command{aclocal} will then take care of automatically adding @file{m4/}
+to its search path for m4 files.
+
+When @samp{aclocal} is run, it will build an @file{aclocal.m4}
that @code{m4_include}s any file from @file{m4/} that defines a
required macro. Macros not found locally will still be searched in
system-wide directories, as explained in @ref{Macro Search Path}.
such third-party macros in your local @file{m4/} directory so they get
distributed.
-Since Automake 1.10, @command{aclocal} offers an option to copy these
-system-wide third-party macros in your local macro directory, solving
-the above problem. Simply use:
-
-@example
-ACLOCAL_AMFLAGS = -I m4 --install
-@end example
+Since Automake 1.10, @command{aclocal} offers the option @code{--install}
+to copy these system-wide third-party macros in your local macro directory,
+helping to solve the above problem.
-@noindent
With this setup, system-wide macros will be copied to @file{m4/}
-the first time you run @command{autoreconf}. Then the locally
-installed macros will have precedence over the system-wide installed
-macros each time @command{aclocal} is run again.
+the first time you run @command{aclocal}. Then the locally installed
+macros will have precedence over the system-wide installed macros
+each time @command{aclocal} is run again.
One reason why you should keep @option{--install} in the flags even
after the first run is that when you later edit @file{configure.ac}
explained in @ref{Local Macros}, and has
@example
-ACLOCAL_AMFLAGS = -I m4 --install
+AC_CONFIG_MACRO_DIRS([m4])
@end example
@noindent
-in its top-level @file{Makefile.am}.
+in its @file{configure.ac}.
Initially the @file{m4/} directory is empty. The first time we run
-@command{autoreconf}, it will fetch the options to pass to
-@command{aclocal} in @file{Makefile.am}, and run @samp{aclocal -I m4
---install}. @command{aclocal} will notice that
+@command{aclocal --install}, it will notice that
@itemize @bullet
@item
copy this file in @file{m4/thirdparty.m4}, and output an
@file{aclocal.m4} that contains @samp{m4_include([m4/thirdparty.m4])}.
-The next time @samp{aclocal -I m4 --install} is run (either via
-@command{autoreconf}, by hand, or from the @file{Makefile} rebuild
-rules) something different happens. @command{aclocal} notices that
+The next time @samp{aclocal --install} is run, something different
+happens. @command{aclocal} notices that
@itemize @bullet
@item
Now suppose the system-wide third-party macro is changed. This can
happen if the package installing this macro is updated. Let's suppose
-the new macro has serial number 2. The next time @samp{aclocal -I m4
---install} is run the situation is the following:
+the new macro has serial number 2. The next time @samp{aclocal --install}
+is run the situation is the following:
@itemize @bullet
@item
version. MyPackage just had its macro updated as a side effect of
running @command{aclocal}.
-If you are leery of letting @command{aclocal} update your local macro,
-you can run @samp{aclocal -I m4 --diff} to review the changes
-@samp{aclocal -I m4 --install} would perform on these macros.
+If you are leery of letting @command{aclocal} update your local
+macro, you can run @samp{aclocal --diff} to review the changes
+@samp{aclocal --install} would perform on these macros.
Finally, note that the @option{--force} option of @command{aclocal} has
absolutely no effect on the files installed by @option{--install}. For
instance, if you have modified your local macros, do not expect
@option{--install --force} to replace the local macros by their
system-wide versions. If you want to do so, simply erase the local
-macros you want to revert, and run @samp{aclocal -I m4 --install}.
+macros you want to revert, and run @samp{aclocal --install}.
@node Future of aclocal
@menu
* Public Macros:: Macros that you can use.
+* Obsolete Macros:: Macros that will soon be removed.
* Private Macros:: Macros that you should not use.
@end menu
Runs many macros required for proper operation of the generated Makefiles.
@vindex AUTOMAKE_OPTIONS
-@code{AM_INIT_AUTOMAKE} is called with a single argument: a space-separated
-list of Automake options that should be applied to every @file{Makefile.am}
-in the tree. The effect is as if each option were listed in
-@code{AUTOMAKE_OPTIONS} (@pxref{Options}).
-
-@c FIXME: Remove this "modernization advice" in Automake 1.14 (and adjust
-@c FIXME: the error message in m4/init.m4:AM_INIT_AUTOMAKE accordingly).
+Today, @code{AM_INIT_AUTOMAKE} is called with a single argument: a
+space-separated list of Automake options that should be applied to
+every @file{Makefile.am} in the tree. The effect is as if
+each option were listed in @code{AUTOMAKE_OPTIONS} (@pxref{Options}).
@acindex AC_INIT
-This macro could once (before Automake 1.13) also be called in the
-@emph{now obsolete and completely unsupported} form
+This macro can also be called in another, @emph{deprecated} form:
@code{AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])}. In this form,
-there were two required arguments: the package and the version number.
+there are two required arguments: the package and the version number.
+This usage is mostly obsolete because the @var{package} and @var{version}
+can be obtained from Autoconf's @code{AC_INIT} macro. However,
+differently from what happens for @code{AC_INIT} invocations, this
+@code{AM_INIT_AUTOMAKE} invocation supports shell variables' expansions
+in the @code{PACKAGE} and @code{VERSION} arguments, and this can be
+still be useful in some selected situations. Our hope is that future
+Autoconf versions will improve their support for package versions
+defined dynamically at configure runtime; when (and if) this happens,
+support for the two-args @code{AM_INIT_AUTOMAKE} invocation will likely
+be removed from Automake.
@anchor{Modernize AM_INIT_AUTOMAKE invocation}
If your @file{configure.ac} has:
@end example
@noindent
-you must modernize it as follows in order to make it work with Automake
-1.13 or later:
+you should modernize it as follows:
@example
AC_INIT([mumble], [1.5])
@opindex no-define
By default this macro @code{AC_DEFINE}'s @code{PACKAGE} and
@code{VERSION}. This can be avoided by passing the @option{no-define}
-option:
+option (@pxref{List of Automake options}):
@example
-AM_INIT_AUTOMAKE([gnits 1.5 no-define dist-bzip2])
+AM_INIT_AUTOMAKE([no-define ...])
@end example
@item AM_PATH_LISPDIR
@end table
+@node Obsolete Macros
+@subsection Obsolete Macros
+@cindex obsolete macros
+@cindex autoupdate
+
+Although using some of the following macros was required in past
+releases, you should not use any of them in new code. @emph{All
+these macros will be removed in the next major Automake version};
+if you are still using them, running @command{autoupdate} should
+adjust your @file{configure.ac} automatically (@pxref{autoupdate
+Invocation, , Using @command{autoupdate} to Modernize
+@file{configure.ac}, autoconf, The Autoconf Manual}).
+@emph{Do it NOW!}
+
+@table @code
+
+@item AM_PROG_MKDIR_P
+@acindex AM_PROG_MKDIR_P
+@cindex @code{mkdir -p}, macro check
+@vindex MKDIR_P
+@vindex mkdir_p
+
+From Automake 1.8 to 1.9.6 this macro used to define the output
+variable @code{mkdir_p} to one of @code{mkdir -p}, @code{install-sh
+-d}, or @code{mkinstalldirs}.
+
+Nowadays Autoconf provides a similar functionality with
+@code{AC_PROG_MKDIR_P} (@pxref{Particular Programs, , Particular
+Program Checks, autoconf, The Autoconf Manual}), however this defines
+the output variable @code{MKDIR_P} instead. In case you are still
+using the @code{AM_PROG_MKDIR_P} macro in your @file{configure.ac},
+or its provided variable @code{$(mkdir_p)} in your @file{Makefile.am},
+you are advised to switch ASAP to the more modern Autoconf-provided
+interface instead; both the macro and the variable might be removed
+in a future major Automake release.
+
+@end table
+
+
@node Private Macros
@subsection Private Macros
built after everything else since they are meant to test what has
been constructed.
+In addition to the built-in recursive targets defined by Automake
+(@code{all}, @code{check}, etc.), the developer can also define his
+own recursive targets. That is done by passing the names of such
+targets as arguments to the m4 macro @code{AM_EXTRA_RECURSIVE_TARGETS}
+in @file{configure.ac}. Automake generates rules to handle the
+recursion for such targets; and the developer can define real actions
+for them by defining corresponding @code{-local} targets.
+
+@example
+% @kbd{cat configure.ac}
+AC_INIT([pkg-name], [1.0]
+AM_INIT_AUTOMAKE
+AM_EXTRA_RECURSIVE_TARGETS([foo])
+AC_CONFIG_FILES([Makefile sub/Makefile sub/src/Makefile])
+AC_OUTPUT
+% @kbd{cat Makefile.am}
+SUBDIRS = sub
+foo-local:
+ @@echo This will be run by "make foo".
+% @kbd{cat sub/Makefile.am}
+SUBDIRS = src
+% @kbd{cat sub/src/Makefile.am}
+foo-local:
+ @@echo This too will be run by a "make foo" issued either in
+ @@echo the 'sub/src/' directory, the 'sub/' directory, or the
+ @@echo top-level directory.
+@end example
+
@node Conditional Subdirectories
@section Conditional Subdirectories
@cindex Subdirectories, building conditionally
@item AM_CFLAGS
This is the variable the @file{Makefile.am} author can use to pass
-in additional C compiler flags. It is more fully documented elsewhere.
-In some situations, this is not used, in preference to the
-per-executable (or per-library) @code{_CFLAGS}.
+in additional C compiler flags. In some situations, this is
+not used, in preference to the per-executable (or per-library)
+@code{_CFLAGS}.
@item COMPILE
This is the command used to actually compile a C source file. The
@end example
Any @file{.vala} file listed in a @code{_SOURCES} variable will be
-compiled into C code by the Vala compiler. The generated @file{.c} files are
-distributed. The end user does not need to have a Vala compiler installed.
+compiled into C code by the Vala compiler. The generated @file{.c} files
+are distributed. The end user does not need to have a Vala compiler installed.
Automake ships with an Autoconf macro called @code{AM_PROG_VALAC}
that will locate the Vala compiler and optionally check its version
number.
-@defmac AM_PROG_VALAC (@ovar{minimum-version})
-Try to find a Vala compiler in @env{PATH}. If it is found, the variable
-@code{VALAC} is set. Optionally a minimum release number of the compiler
-can be requested:
-
-@example
-AM_PROG_VALAC([0.7.0])
-@end example
+@defmac AM_PROG_VALAC (@ovar{minimum-version}, @ovar{action-if-found},
+ @ovar{action-if-not-found})
+Search for a Vala compiler in @env{PATH}. If it is found, the variable
+@code{VALAC} is set to point to it (see below for more details). This
+macro takes three optional arguments. The first argument, if present,
+is the minimum version of the Vala compiler required to compile this
+package. If a compiler is found and satisfies @var{minimum-version},
+then @var{action-if-found} is run (this defaults to do nothing).
+Otherwise, @var{action-if-not-found} is run. If @var{action-if-not-found}
+is not specified, the default value is to print a warning in case no
+compiler is found, or if a too-old version of the compiler is found.
@end defmac
There are a few variables that are used when compiling Vala sources:
@vtable @code
@item VALAC
-Path to the Vala compiler.
+Absolute path to the Vala compiler, or simply @samp{valac} if no
+suitable compiler Vala could be found at configure runtime.
@item VALAFLAGS
Additional arguments for the Vala compiler.
distributed.
Automake will byte-compile all Emacs Lisp source files using the Emacs
-found by @code{AM_PATH_LISPDIR}, if any was found.
+found by @code{AM_PATH_LISPDIR}, if any was found. When performing such
+byte-compilation, the flags specified in the (developer-reserved)
+@code{AM_ELCFLAGS} and (user-reserved) @code{ELCFLAGS} make variables
+will be passed to the Emacs invocation.
Byte-compiled Emacs Lisp files are not portable among all versions of
Emacs, so it makes sense to turn this off if you expect sites to have
Automake provides some minimal support for Java bytecode compilation with
the @code{JAVA} primary (in addition to the support for compiling Java to
native machine code; @pxref{Java Support with gcj}). Note however that
-@emph{the interface and most features described here are deprecated}; the
-next automake release will strive to provide a better and cleaner
+@emph{the interface and most features described here are deprecated}.
+Future Automake releases will strive to provide a better and cleaner
interface, which however @emph{won't be backward-compatible}; the present
-interface will probably be removed altogether in future automake releases
-(1.13 or later), so don't use it in new code.
+interface will probably be removed altogether some time after the
+introduction of the new interface (if that ever materializes).
Any @file{.java} files listed in a @code{_JAVA} variable will be
compiled with @code{JAVAC} at build time. By default, @file{.java}
If the current directory contains Texinfo source, you must declare it
with the @code{TEXINFOS} primary. Generally Texinfo files are converted
into info, and thus the @code{info_TEXINFOS} variable is most commonly used
-here. Any Texinfo source file must end in the @file{.texi},
-@file{.txi}, or @file{.texinfo} extension. We recommend @file{.texi}
-for new manuals.
+here. Any Texinfo source file should have the @file{.texi} extension.
+Automake also accepts @file{.txi} or @file{.texinfo} extensions, but their
+use is discouraged now, and will elicit runtime warnings.
Automake generates rules to build @file{.info}, @file{.dvi},
@file{.ps}, @file{.pdf} and @file{.html} files from your Texinfo
request this explicitly using @samp{make install-info}.
@vindex AM_UPDATE_INFO_DIR
-By default, @code{make install-info} and @code{make install-info}
-will try to run the @command{install-info} program (if available)
-to update (or create) the @file{@code{$@{infodir@}}/dir} index.
+By default, @code{make install-info} and @code{make uninstall-info}
+will try to run the @command{install-info} program (if available) to
+update (or create/remove) the @file{@code{$@{infodir@}}/dir} index.
If this is undesired, it can be prevented by exporting the
@code{AM_UPDATE_INFO_DIR} variable to "@code{no}".
@samp{$(AM_MAKEINFOHTMLFLAGS)} is used when building @file{.html}
files.
-@c Keep in sync with txinfo21.sh
+@c Keep in sync with txinfo-many-output-formats.sh
For instance, the following setting can be used to obtain one single
@file{.html} file per manual, without node separators.
@example
rm -rf `find $(distdir)/doc -type d -name .svn`
@end example
-@c The caveates described here should be documented in 'disthook.test'.
+@c The caveates described here should be documented in 'disthook.sh'.
@noindent
Note that the @code{dist-hook} recipe shouldn't assume that the regular
files in the distribution directory are writable; this might not be the
distributions in various formats. Their targets are:
@table @asis
+@item @code{dist-gzip}
+Generate a @samp{gzip} tar archive of the distribution. This is the
+only format enabled by default.
+@trindex dist-gzip
+
@vindex BZIP2
@item @code{dist-bzip2}
-Generate a bzip2 tar archive of the distribution. bzip2 archives are
-frequently smaller than gzipped archives.
+Generate a @samp{bzip2} tar archive of the distribution. bzip2 archives
+are frequently smaller than gzipped archives.
By default, this rule makes @samp{bzip2} use a compression option of @option{-9}.
To make it use a different one, set the @env{BZIP2} environment variable.
For example, @samp{make dist-bzip2 BZIP2=-7}.
@trindex dist-bzip2
-@item @code{dist-gzip}
-Generate a gzip tar archive of the distribution.
-@trindex dist-gzip
-
@item @code{dist-lzip}
Generate an @samp{lzip} tar archive of the distribution. @command{lzip}
archives are frequently smaller than @command{bzip2}-compressed archives.
@trindex dist-lzip
-@item @code{dist-shar}
-Generate a shar archive of the distribution.
-@trindex dist-shar
-
@vindex XZ_OPT
@item @code{dist-xz}
Generate an @samp{xz} tar archive of the distribution. @command{xz}
@option{-e}. To make it use a different one, set the @env{XZ_OPT}
environment variable. For example, run this command to use the
default compression ratio, but with a progress indicator:
-@samp{make dist-xz XZ_OPT=-7e}.
+@samp{make dist-xz XZ_OPT=-ve}.
@trindex dist-xz
@item @code{dist-zip}
-Generate a zip archive of the distribution.
+Generate a @samp{zip} archive of the distribution.
@trindex dist-zip
@item @code{dist-tarZ}
-Generate a compressed tar archive of
-the distribution.
+Generate a tar archive of the distribution, compressed with the
+historical (obsolescent) program @command{compress}. Use of this
+option is discouraged.
@trindex dist-tarZ
+
+@item @code{dist-shar}
+Generate a @samp{shar} archive of the distribution. This format archive
+is obsolescent, and use of this option is discouraged.
+@trindex dist-shar
+
@end table
-The rule @code{dist} (and its historical synonym @code{dist-all}) will
-create archives in all the enabled formats, @ref{Options}. By
-default, only the @code{dist-gzip} target is hooked to @code{dist}.
+The rule @code{dist} (and its historical synonym @code{dist-all})
+will create archives in all the enabled formats (@pxref{List of
+Automake options} for how to change this list). By default, only
+the @code{dist-gzip} target is hooked to @code{dist}.
@node Tests
@menu
* Scripts-based Testsuites:: Automake-specific concepts and terminology
-* Serial Test Harness:: Older (and obsolescent) serial test harness
+* Serial Test Harness:: Older (and discouraged) serial test harness
* Parallel Test Harness:: Generic concurrent test harness
@end menu
@anchor{Simple tests and color-tests}
@vindex AM_COLOR_TESTS
@cindex Colorized testsuite output
-If the Automake option @code{color-tests} is used (@pxref{Options})
-and standard output is connected to a capable terminal, then the test
-results and the summary are colored appropriately. The user can disable
-colored output by setting the @command{make} variable
-@samp{AM_COLOR_TESTS=no}, or force colored output even without a connecting
-terminal with @samp{AM_COLOR_TESTS=always}. It's also worth noting that
-some @command{make} implementations, when used in parallel mode, have
-slightly different semantics (@pxref{Parallel make,,, autoconf,
-The Autoconf Manual}), which can break the automatic detection of a
-connection to a capable terminal. If this is the case, you'll have to
-resort to the use of @samp{AM_COLOR_TESTS=always} in order to have the
-testsuite output colorized.
+If the standard output is connected to a capable terminal, then the test
+results and the summary are colored appropriately. The developer and the
+user can disable colored output by setting the @command{make} variable
+@samp{AM_COLOR_TESTS=no}; the user can in addition force colored output
+even without a connecting terminal with @samp{AM_COLOR_TESTS=always}.
+It's also worth noting that some @command{make} implementations,
+when used in parallel mode, have slightly different semantics
+(@pxref{Parallel make,,, autoconf, The Autoconf Manual}), which can
+break the automatic detection of a connection to a capable terminal.
+If this is the case, the user will have to resort to the use of
+@samp{AM_COLOR_TESTS=always} in order to have the testsuite output
+colorized.
Test programs that need data files should look for them in @code{srcdir}
(which is both a make variable and an environment variable made available
@code{TESTS = $(check_PROGRAMS)} if all your programs are test cases.
@node Serial Test Harness
-@subsection Older (and obsolescent) serial test harness
+@subsection Older (and discouraged) serial test harness
@cindex @option{serial-tests}, Using
-@emph{This harness is obsolescent}, and kept for backward-compatibility
-reasons only. The user is strongly advised to just use the parallel test
-harness instead (@pxref{Parallel Test Harness}).
+First, note that today the use of this harness is strongly discouraged in
+favour of the parallel test harness (@pxref{Parallel Test Harness}).
+Still, there are @emph{few} situations when the advantages offered by
+the parallel harness are irrelevant, and when test concurrency can
+even cause tricky problems. In those cases, it might make sense to
+still use the serial harness, for simplicity and reliability (we still
+suggest trying to give the parallel harness a shot though).
The serial test harness is enabled by the Automake option
@option{serial-tests}. It operates by simply running the tests serially,
of inter-test dependencies, lazy reruns of tests that have not completed
in a prior run, and hard errors for exceptional failures.
-This harness is still somewhat experimental and may undergo changes in
-order to satisfy additional portability requirements.
-
@anchor{Basics of test metadata}
@vindex TEST_SUITE_LOG
@vindex TESTS
For example, @samp{.sh}, @samp{.T} and @samp{.t1} are valid extensions,
while @samp{.x-y}, @samp{.6c} and @samp{.t.1} are not.
+@cindex Configure substitutions in @code{TESTS}
+It is important to note that, due to current limitations (unlikely to be
+lifted), configure substitutions in the definition of @code{TESTS} can
+only work if they will expand to a list of tests that have a suffix listed
+in @code{TEST_EXTENSIONS}.
+
@vindex _LOG_COMPILE
@vindex _LOG_COMPILER
@vindex _LOG_FLAGS
concurrent execution.
@cindex Unit tests
-@c Keep in sync with 'parallel-tests-extra-programs.test'.
+@c Keep in sync with 'parallel-tests-extra-programs.sh'.
The combination of lazy test execution and correct dependencies between
tests and their sources may be exploited for efficient unit testing
during development. To further speed up the edit-compile-test cycle, it
@end itemize
@noindent
-On the other hand, the exact semantics of how (and if)
-@option{color-tests}, @code{XFAIL_TESTS}, and hard errors are supported
-and handled is left to the individual test drivers.
+On the other hand, the exact semantics of how (and if) testsuite output
+colorization, @code{XFAIL_TESTS}, and hard errors are supported and
+handled is left to the individual test drivers.
@c TODO: We should really add a working example in the doc/ directory,
@c TODO: and reference if from here.
test; the harness will ignore such extra text when generating
@file{test-suite.log} and preparing the testsuite summary.
-@c Keep in sync with 'test-metadata-recheck.test'.
+@c Keep in sync with 'test-metadata-recheck.sh'.
@item @code{:recheck:}
@cindex :recheck:
@cindex reStructuredText field, @code{:recheck:}
happens when two or more @code{:recheck:} fields are present in the same
@file{.trs} file is undefined behaviour.
-@c Keep in sync with 'test-metadata-global-log.test'.
+@c Keep in sync with 'test-metadata-global-log.sh'.
@item @code{:copy-in-global-log:}
@cindex :copy-in-global-log:
@cindex reStructuredText field, @code{:copy-in-global-log:}
successful. What happens when two or more @code{:copy-in-global-log:}
fields are present in the same @file{.trs} file is undefined behaviour.
-@c Keep in sync with 'test-metadata-global-result.test'.
+@c Keep in sync with 'test-metadata-global-result.sh'.
@item @code{:test-global-result:}
@cindex :test-global-result:
@cindex reStructuredText field, @code{:test-global-result:}
compatibility with the @command{prove} utility.
@table @option
-@c Keep in sync with 'tap-exit.test' and 'tap-signal.tap'.
+@c Keep in sync with 'tap-exit.sh' and 'tap-signal.tap'.
@item --ignore-exit
Causes the test driver to ignore the exit status of the test scripts;
by default, the driver will report an error if the script exits with a
If you are using @code{AM_MAINTAINER_MODE} in @file{configure.ac}, then
these automatic rebuilding rules are only enabled in maintainer mode.
-@vindex ACLOCAL_AMFLAGS
-Sometimes you need to run @command{aclocal} with an argument like
-@option{-I} to tell it where to find @file{.m4} files. Since
-sometimes @command{make} will automatically run @command{aclocal}, you
-need a way to specify these arguments. You can do this by defining
-@code{ACLOCAL_AMFLAGS}; this holds arguments that are passed verbatim
-to @command{aclocal}. This variable is only useful in the top-level
-@file{Makefile.am}.
-
@vindex CONFIG_STATUS_DEPENDENCIES
@vindex CONFIGURE_DEPENDENCIES
@cindex @file{version.sh}, example
cause @file{configure} to be rerun each time @file{version.sh} is
changed.
+@c Keep in sync with remake-config-status-dependencies.sh
@example
AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version.sh'])
@end example
Beware not to mistake @code{CONFIGURE_DEPENDENCIES} for
@code{CONFIG_STATUS_DEPENDENCIES}.
+@c Keep in sync with remake-configure-dependencies.sh
@code{CONFIGURE_DEPENDENCIES} adds dependencies to the
@file{configure} rule, whose effect is to run @command{autoconf}. This
variable should be seldom used, because @command{automake} already tracks
@code{m4_include}d files. However it can be useful when playing
tricky games with @code{m4_esyscmd} or similar non-recommendable
-macros with side effects.
+macros with side effects. Be also aware that interactions of this
+variable with the @ref{Autom4te Cache, , autom4te cache, autoconf,
+The Autoconf Manual} are quite problematic and can cause subtle
+breakage, so you might want to disable the cache if you want to use
+@code{CONFIGURE_DEPENDENCIES}.
@code{CONFIG_STATUS_DEPENDENCIES} adds dependencies to the
@file{config.status} rule, whose effect is to run @file{configure}.
in the example above.
Speaking of @file{version.sh} scripts, we recommend against them
-today. We recommend that @file{version.sh} be replaced by an M4 file
-that is included by @file{configure.ac}:
+today. They are mainly used when the version of a package is updated
+automatically by a script (e.g., in daily builds). Here is what some
+old-style @file{configure.ac}s may look like:
+
+@example
+AC_INIT
+. $srcdir/version.sh
+AM_INIT_AUTOMAKE([name], $VERSION_NUMBER)
+@dots{}
+@end example
+
+@noindent
+Here, @file{version.sh} is a shell fragment that sets
+@code{VERSION_NUMBER}. The problem with this example is that
+@command{automake} cannot track dependencies (listing @file{version.sh}
+in @command{CONFIG_STATUS_DEPENDENCIES}, and distributing this file is up
+to the user), and that it uses the obsolete form of @code{AC_INIT} and
+@code{AM_INIT_AUTOMAKE}. Upgrading to the new syntax is not
+straightforward, because shell variables are not allowed in
+@code{AC_INIT}'s arguments. We recommend that @file{version.sh} be
+replaced by an M4 file that is included by @file{configure.ac}:
@example
m4_include([version.m4])
@samp{m4_define([VERSION_NUMBER], [1.2])}. The advantage of this
second form is that @command{automake} will take care of the
dependencies when defining the rebuild rule, and will also distribute
-the file automatically.
+the file automatically. An inconvenience is that @command{autoconf}
+will now be rerun each time the version number is bumped, when only
+@file{configure} had to be rerun in the previous setup.
@node Options
Cause @samp{make dist} to fail unless the current version number appears
in the first few lines of the @file{NEWS} file.
-@item @option{color-tests}
-@cindex Option, @option{color-tests}
-@opindex color-tests
-Cause output of the serial and parallel test harnesses (see @ref{Simple
-Tests}) and of properly-written custom test drivers (@pxref{Custom Test
-Drivers}) to be colorized on capable terminals.
-
@item @option{dejagnu}
@cindex Option, @option{dejagnu}
@opindex dejagnu
Hook @code{dist-lzip} to @code{dist}.
@trindex dist-lzip
-@item @option{dist-shar}
-@cindex Option, @option{dist-shar}
-@opindex dist-shar
-Hook @code{dist-shar} to @code{dist}.
-@trindex dist-shar
+@item @option{dist-xz}
+@cindex Option, @option{dist-xz}
+@opindex dist-xz
+Hook @code{dist-xz} to @code{dist}.
+@trindex dist-xz
@item @option{dist-zip}
@cindex Option, @option{dist-zip}
Hook @code{dist-zip} to @code{dist}.
@trindex dist-zip
+@item @option{dist-shar}
+@cindex Option, @option{dist-shar}
+@opindex dist-shar
+Hook @code{dist-shar} to @code{dist}. Use of this option
+is discouraged, as the @samp{shar} format is obsolescent and
+problematic.
+@trindex dist-shar
+
@item @option{dist-tarZ}
@cindex Option, @option{dist-tarZ}
@opindex dist-tarZ
-Hook @code{dist-tarZ} to @code{dist}.
+Hook @code{dist-tarZ} to @code{dist}. Use of this option
+is discouraged, as the @samp{compress} program is obsolete.
@trindex dist-tarZ
@item @option{filename-length-max=99}
not portable to other @command{make} implementations.
The only way Automake could support @command{$(wildcard ...)} is by
-expending @command{$(wildcard ...)} when @command{automake} is run.
+expanding @command{$(wildcard ...)} when @command{automake} is run.
The resulting @file{Makefile.in}s would be portable since they would
list all files and not use @samp{$(wildcard ...)}. However that
means developers would need to remember to run @command{automake} each
@code{MAKEFLAGS} is passed to sub-@command{make}s implicitly by
@command{make} itself.
-However you should not think that all variables ending with @code{FLAGS}
-follow this convention. For instance, @code{ACLOCAL_AMFLAGS} (see
-@ref{Rebuilding} and @ref{Local Macros}) is a variable that is only
-useful to the maintainer and has no user counterpart.
-
@code{ARFLAGS} (@pxref{A Library}) is usually defined by Automake and
has neither @code{AM_} nor per-target cousin.
projects / platform / upstream / automake.git / blobdiff