VPATH builds have other interesting uses. One is to build the same
sources with multiple configurations. For instance:
-@c Keep in sync with amhello-cflags.test.
+@c Keep in sync with amhello-cflags.sh
@example
~ % @kbd{tar zxf ~/amhello-1.0.tar.gz}
~ % @kbd{cd amhello-1.0}
Here is how we could build @code{amhello-1.0} for
@code{i586-mingw32msvc} on a GNU/Linux PC.
-@c Keep in sync with amhello-cross-compile.test.
+@c Keep in sync with amhello-cross-compile.sh
@smallexample
~/amhello-1.0 % @kbd{./configure --build i686-pc-linux-gnu --host i586-mingw32msvc}
checking for a BSD-compatible install... /usr/bin/install -c
For instance here is how we could create a binary package containing a
snapshot of all the files to be installed.
-@c Keep in sync with amhello-binpkg.test.
+@c Keep in sync with amhello-binpkg.sh
@example
~/amhello-1.0 % @kbd{./configure --prefix /usr}
@dots{}
Generally, Automake is not particularly smart in the parsing of unusual
Makefile constructs, so you're advised to avoid fancy constructs or
``creative'' use of whitespaces.
-@c Keep this in sync with doc-parsing-buglets-tabs.test.
+@c Keep this in sync with doc-parsing-buglets-tabs.sh
For example, @key{TAB} characters cannot be used between a target name
and the following ``@code{:}'' character, and variable assignments
shouldn't be indented with @key{TAB} characters.
-@c Keep this in sync with doc-parsing-buglets-colneq-subst.test.
+@c Keep this in sync with doc-parsing-buglets-colneq-subst.sh
Also, using more complex macro in target names can cause trouble:
@example
variables referenced in the definition. For example, if Automake is
looking at the content of @code{foo_SOURCES} in this snippet
-@c Keep in sync with interp.test.
+@c Keep in sync with interp.sh
@example
xs = a.c b.c
foo_SOURCES = c.c $(xs)
For instance, the following snippet will install @file{file.xml} into
@samp{$(datadir)/xml}.
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
xmldir = $(datadir)/xml
xml_DATA = file.xml
unlikely case these checks are undesirable, and you really know what
you're doing). For example, Automake would error out on this input:
-@c Should be tested in primary-prefix-invalid-couples.test.
+@c Should be tested in primary-prefix-invalid-couples.sh
@example
# Forbidden directory combinations, automake will error out on this.
pkglib_PROGRAMS = foo
@noindent
but it will succeed with this:
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
# Work around forbidden directory combinations. Do not use this
# without a very good reason!
@noindent
may also be written as
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
data_DATA = file1 @dots{} file@var{N}
data2dir = $(datadir)
@code{false} in real life, you would probably use per-program
compilation flags, like so:
-@c Keep in sync with specflg7.test and specflg8.test.
+@c Keep in sync with specflg7.sh and specflg8.sh
@example
bin_PROGRAMS = false true
On the other hand, the @option{silent-rules} options (@pxref{Options})
turns off portability warnings about recursive variable expansions.
-@c Checked by extra-portability.test
+@c Checked by extra-portability.sh
Turning off @samp{portability} will also turn off @samp{extra-portability},
and similarly turning on @samp{extra-portability} will also turn on
@samp{portability}. However, turning on @samp{portability} or turning
@command{automake} will not be able to fulfill this setup, and you will
have to complete the missing bits by hand. For instance, on
-@c Keep in sync with output11.test.
+@c Keep in sync with output11.sh
@example
file=input
@dots{}
Similarly
-@c Keep in sync with output11.test.
+@c Keep in sync with output11.sh
@example
file=output
file2=out:in
Install system-wide third-party macros into the first directory
specified with @samp{-I @var{dir}} instead of copying them in the
output file.
-@c The following semantics is checked by `aclocal-install-absdir.test'.
+@c Keep in sync with aclocal-install-absdir.sh
Note that this will happen also if @var{dir} is an absolute path.
@cindex serial number and @option{--install}
The fourth and last mechanism to customize the macro search path is
also the simplest. Any directory included in the colon-separated
environment variable @env{ACLOCAL_PATH} is added to the search path
-@c Keep in sync with aclocal-path-precedence.test.
+@c Keep in sync with aclocal-path-precedence.sh
and takes precedence over system directories (including those found via
@file{dirlist}), with the exception of the versioned directory
@var{acdir-APIVERSION} (@pxref{Macro Search Path}). However, directories
passed via @option{-I} will take precedence over directories in
@env{ACLOCAL_PATH}.
-@c Keep in sync with aclocal-path-installed.test.
+@c Keep in sync with aclocal-path-installed.sh
Also note that, if the @option{--install} option is used, any @file{.m4}
file containing a required macro that is found in a directory listed in
@env{ACLOCAL_PATH} will be installed locally.
-@c Keep in sync with aclocal-path-installed-serial.test.
+@c Keep in sync with aclocal-path-installed-serial.sh
In this case, serial numbers in @file{.m4} are honoured too,
@pxref{Serials}.
A macro file's name should end in @file{.m4}. Such files should be
installed in @file{$(datadir)/aclocal}. This is as simple as writing:
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
aclocaldir = $(datadir)/aclocal
aclocal_DATA = mymacro.m4 myothermacro.m4
@cindex @code{SUBDIRS} and @code{AM_CONDITIONAL}
@cindex @code{AM_CONDITIONAL} and @code{SUBDIRS}
-@c Keep in sync with subcond2.test.
+@c Keep in sync with subcond2.sh
@file{configure} should output the @file{Makefile} for each directory
and define a condition into which @file{opt/} should be built.
@cindex @code{SUBDIRS} and @code{AC_SUBST}
@cindex @code{AC_SUBST} and @code{SUBDIRS}
-@c Keep in sync with subcond3.test.
+@c Keep in sync with subcond3.sh
Another possibility is to define @code{MAYBE_OPT} from
@file{./configure} using @code{AC_SUBST}:
directory (@pxref{Uniform}). For instance, the last example could be
rewritten as follows:
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
imagesdir = $(pkgdatadir)/images
soundsdir = $(pkgdatadir)/sounds
select programs to be built. In this case you don't have to worry
about @samp{$(EXEEXT)} or @code{EXTRA_PROGRAMS}.
-@c Keep in sync with exeext.test.
+@c Keep in sync with exeext.sh
@example
bin_PROGRAMS = cpio pax
if WANT_MT
@code{@var{library}_LIBADD} variable. This should be used for objects
determined by @command{configure}. Again from @code{cpio}:
-@c Keep in sync with pr401c.test.
+@c Keep in sync with pr401c.sh
@example
libcpio_a_LIBADD = $(LIBOBJS) $(ALLOCA)
@end example
the link rule for these two libraries. Therefore the @option{-rpath}
argument must be explicitly supplied.
-@c Keep in sync with ltcond.test.
+@c Keep in sync with ltcond.sh
@example
EXTRA_LTLIBRARIES = libfoo.la libbar.la
lib_LTLIBRARIES = $(WANTEDLIBS)
it's clear that both libraries will end up in @samp{$(libdir)} if they
are installed.
-@c Keep in sync with ltcond.test.
+@c Keep in sync with ltcond.sh
@example
lib_LTLIBRARIES =
if WANT_LIBFOO
@file{hello-linux.c} or @file{hello-generic.c} with the following
@file{Makefile.am}.
-@c Keep in sync with ltcond2.test.
+@c Keep in sync with ltcond2.sh
@example
lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello-common.c
Or we could simply use an Automake conditional as follows.
-@c Keep in sync with ltcond2.test.
+@c Keep in sync with ltcond2.sh
@example
lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello-common.c
Here is a sample setup merging libtool convenience libraries from
subdirectories into one main @file{libtop.la} library.
-@c Keep in sync with ltconv.test.
+@c Keep in sync with ltconv.sh
@example
# -- Top-level Makefile.am --
SUBDIRS = sub1 sub2 @dots{}
Since Automake 1.8, we now recommend using @code{lisp_DATA} instead:
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
lisp_DATA = file1.el file2.el
@end example
Here is a typical setup for distributing @file{.java} files and
installing the @file{.class} files resulting from their compilation.
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
javadir = $(datadir)/java
dist_java_JAVA = a.java b.java @dots{}
that will determine some Python-related directory variables (see
below). If you have called @code{AM_PATH_PYTHON} from
@file{configure.ac}, then you may use the variables
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@code{python_PYTHON} or @code{pkgpython_PYTHON} to list Python source
files in your @file{Makefile.am}, depending on where you want your files
installed (see the definitions of @code{pythondir} and
should be installed. An extension module written in C could be declared
as follows to Automake:
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@example
pyexec_LTLIBRARIES = quaternion.la
quaternion_la_SOURCES = quaternion.c support.c support.h
@samp{$(AM_MAKEINFOHTMLFLAGS)} is used when building @file{.html}
files.
-@c Keep in sync with txinfo21.test.
+@c Keep in sync with txinfo21.sh
For instance, the following setting can be used to obtain one single
@file{.html} file per manual, without node separators.
@example
Any variable using a user-defined directory prefix with
@samp{exec} in the name (e.g.,
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
@code{myexecbin_PROGRAMS}) is installed by @code{install-exec}. All
other user-defined prefixes are installed by @code{install-data}.
or as the target of a @file{Makefile.am} rule); this list is printed by
@samp{automake --help}. Note that some files in this list are actually
distributed only if other certain conditions hold (for example,
-@c Keep in sync with autodist-config-headers.test.
+@c Keep in sync with autodist-config-headers.sh
the @file{config.h.top} and @file{config.h.bot} files are automatically
distributed only if, e.g., @samp{AC_CONFIG_HEADERS([config.h])} is used
in @file{configure.ac}). Also, files that are read by @command{configure}
been cleaned because they are also part of the distribution, add the
following definition instead:
-@c Keep in sync with distcleancheck.test.
+@c Keep in sync with distcleancheck.sh
@example
distcleancheck_listfiles = \
find . -type f -exec sh -c 'test -f $(srcdir)/$$1 || echo $$1' \
Note however that, for tests based on more complex test protocols,
the exact effects of @code{XFAIL_TESTS} and @code{DISABLE_HARD_ERRORS}
might change, or they might even have no effect at all (for example,
-@c Keep this in sync with tap-no-disable-hard-errors.test.
+@c Keep this in sync with tap-no-disable-hard-errors.sh
in tests using TAP, there is not way to disable hard errors, and the
@code{DISABLE_HARD_ERRORS} variable has no effect on them).
@code{SKIP}, @code{XFAIL}, @code{XPASS} and @code{ERROR}. Here is an
example of output from an hypothetical testsuite that uses both plain
and TAP tests:
-@c Keep in sync with tap-doc.test.
+@c Keep in sync with tap-doc.sh
@example
PASS: foo.sh
PASS: zardoz.tap 1 - Daemon started
@c FIXME: should we offer a link to the relevant discussions on the
@c bug-autoconf list?
-@c Keep in sync with tests-environment-backcompat.test.
+@c Keep in sync with tests-environment-backcompat.sh
@example
AM_TESTS_ENVIRONMENT = \
## Some environment initializations are kept in a separate shell
overridden by the user, in which case any extension listed in it must be
constituted by a dot, followed by a non-digit alphabetic character,
followed by any number of alphabetic characters.
-@c Keep in sync with test-extensions.test.
+@c Keep in sync with test-extensions.sh
For example, @samp{.sh}, @samp{.T} and @samp{.t1} are valid extensions,
while @samp{.x-y}, @samp{.6c} and @samp{.t.1} are not.
tests without a registered extension, the variables @code{LOG_COMPILER},
@code{AM_LOG_FLAGS}, and @code{LOG_FLAGS} may be used. For example,
-@c Keep in sync with parallel-tests-log-compiler-example.test.
+@c Keep in sync with parallel-tests-log-compiler-example.sh
@example
TESTS = foo.pl bar.py baz
TEST_EXTENSIONS = .pl .py
easily be avoided by overriding also @code{TEST_SUITE_LOG} at runtime;
for example,
-@c Keep in sync with parallel-tests-log-override-2.test.
+@c Keep in sync with parallel-tests-log-override-2.sh
@example
env TEST_SUITE_LOG=partial.log TESTS="..." make -e check
@end example
@noindent
Here is an example of how the TAP driver can be set up and used.
-@c Keep in sync with tap-doc2.test.
+@c Keep in sync with tap-doc2.sh
@example
% @kbd{cat configure.ac}
AC_INIT([GNU Try Tap], [1.0], [bug-automake@@gnu.org])
the @samp{.idlC.cpp:} rule as an attempt to transform @file{.idlC} files into
@file{.cpp} files.
-@c Keep in sync with suffix7.test.
+@c Keep in sync with suffix7.sh
@example
SUFFIXES = .idl C.cpp
.idlC.cpp:
adding a @samp{yes} argument to the @code{AM_SILENT_RULES} call in
@file{configure.ac}. We advise against this approach, though.
-@c Keep in sync with silent-configsite.test
+@c Keep in sync with silent-configsite.sh
Users who prefer to have silent rules enabled by default can edit their
@file{config.site} file to make the variable @code{enable_silent_rules}
default to @samp{yes}. This should still allow disabling silent rules
For instance, here is how you could install a versioned copy of a
program using @samp{$(LN_S)}:
-@c Keep in sync with insthook.test
+@c Keep in sync with insthook.sh
@example
install-exec-hook:
cd $(DESTDIR)$(bindir) && \
please bear in mind that the exec/data distinction is based on the
installation directory, not on the primary used (@pxref{The Two Parts of
Install}).
-@c Keep in sync with primary-prefix-couples-documented-valid.test.
+@c Keep in sync with primary-prefix-couples-documented-valid.sh
So a @code{foo_SCRIPTS} will be installed by
@code{install-data}, and a @code{barexec_SCRIPTS} will be installed by
@code{install-exec}. You should define your hooks consequently.