@cindex @file{amhello-1.0.tar.gz}, use cases
In this section we explore several use cases for the GNU Build System.
-You can replay all these examples on the @file{amhello-1.0.tar.gz}
+You can replay all of these examples on the @file{amhello-1.0.tar.gz}
package distributed with Automake. If Automake is installed on your
system, you should find a copy of this file in
@file{@var{prefix}/share/doc/automake/amhello-1.0.tar.gz}, where
@command{autoreconf} is a script that calls @command{autoconf},
@command{automake}, and a bunch of other commands in the right order.
If you are beginning with these tools, it is not important to figure
-out in which order all these tools should be invoked and why. However,
+out in which order all of these tools should be invoked and why. However,
because Autoconf and Automake have separate manuals, the important
point to understand is that @command{autoconf} is in charge of
creating @file{configure} from @file{configure.ac}, while
that is compatible with @command{make}'s syntax) and furthermore use
@code{AC_SUBST} to ensure that @samp{$@{file@}} is meaningful in a
@file{Makefile}, then @command{automake} will be able to use
-@samp{$@{file@}} to generate all these rules. For instance, here is
+@samp{$@{file@}} to generate all of these rules. For instance, here is
how the Automake package itself generates versioned scripts for its
test suite:
and many third party macros are underquoted; and we have to apologize
for this temporary inconvenience. The reason we have to be stricter
is that a future implementation of @command{aclocal} (@pxref{Future of
-aclocal}) will have to temporarily include all these third party
+aclocal}) will have to temporarily include all of these third party
@file{.m4} files, maybe several times, including even files that are
not actually needed. Doing so should alleviate many problems of the
current implementation, however it requires a stricter style from the
@vindex ACLOCAL_AMFLAGS
The second possibility, which we do recommend, is to write each macro
-in its own file and gather all these files in a directory. This
+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
built after everything else since they are meant to test what has
been constructed.
-All @code{clean} rules are run in reverse order of build rules.
-
@node Conditional Subdirectories
@section Conditional Subdirectories
@cindex Subdirectories, building conditionally
@cindex @code{SUBDIRS} and @code{AM_CONDITIONAL}
@cindex @code{AM_CONDITIONAL} and @code{SUBDIRS}
-@c Keep in sync with subcond2.sh
+@c Keep in sync with subdir-am-cond.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.sh
+@c Keep in sync with subdir-ac-subst.sh
Another possibility is to define @code{MAYBE_OPT} from
@file{./configure} using @code{AC_SUBST}:
@samp{$(pyexecdir)/$(PACKAGE)}.
@end vtable
-All these directory variables have values that start with either
+All of these directory variables have values that start with either
@samp{$@{prefix@}} or @samp{$@{exec_prefix@}} unexpanded. This works
fine in @file{Makefiles}, but it makes these variables hard to use in
@file{configure}. This is mandated by the GNU coding standards, so
documentation installed by default as well as all the above optional
formats.
-All these targets can be extended using @samp{-local} rules
+All of these targets can be extended using @samp{-local} rules
(@pxref{Extending}).
@cindex Texinfo flag, @code{VERSION}
how third-party @file{Makefile}s can be used with Automake. The
@file{Makefile}s @command{gettextize} puts in the @file{po/} and
@file{intl/} directories are handwritten @file{Makefile}s that
-implement all these targets. That way they can be added to
+implement all of these targets. That way they can be added to
@code{SUBDIRS} in Automake packages.
Directories that are only listed in @code{DIST_SUBDIRS} but not in
definitions of the M4 macros put in @file{aclocal.m4} as well as the
behavior of the auxiliary tools installed.
-Because all these files are closely related, it is important to
+Because all of these files are closely related, it is important to
regenerate all of them when upgrading to a newer Automake release.
The usual way to do that is
The use of @option{--force-missing} ensures that auxiliary tools will be
overridden by new versions (@pxref{automake Invocation}).
-It is important to regenerate all these files each time Automake is
+It is important to regenerate all of these files each time Automake is
upgraded, even between bug fixes releases. For instance, it is not
unusual for a bug fix to involve changes to both the rules generated
in @file{Makefile.in} and the supporting M4 macros copied to
folks have such a script).
@item
Or @file{configure.ac} uses @code{AM_MAINTAINER_MODE}, which will
-disable all these rebuild rules by default. This is further discussed
+disable all of these rebuild rules by default. This is further discussed
in @ref{maintainer-mode}.
@end itemize
Using variables like this gives you full control over the ordering of
the flags. For instance, if there is a flag in $(WARNINGCFLAGS) that
you want to negate for a particular target, you can use something like
-@samp{prog1_CFLAGS = $(AM_CFLAGS) -no-flag}. If all these flags had
+@samp{prog1_CFLAGS = $(AM_CFLAGS) -no-flag}. If all of these flags had
been forcefully appended to @code{CFLAGS}, there would be no way to
disable one flag. Yet another reason to leave user variables to
users.
projects / platform / upstream / automake.git / blobdiff