It's only the beginning: in two months he will send 192 patches. Then
he would slow down so Tom can catch up and review all this. Initially
-Tom actually read all these patches, then he probably trustingly
+Tom actually read all of these patches, then he probably trustingly
answered OK to most of them, and finally gave up and let Akim apply
whatever he wanted. There was no way to keep up with that patch rate.
been moved :) -- Alexandre Duret-Lutz
@end quotation
-All these patches were sent to and discussed on
+All of these patches were sent to and discussed on
@email{automake@@gnu.org}, so subscribed users were literally drowning in
technical mails. Eventually, the @email{automake-patches@@gnu.org}
mailing list was created in May.
various places in the @command{automake} script itself; this does not
help ensuring a consistent treatment of these rules (for instance
making sure that user-defined rules override Automake's own rules).
-One of Akim's goal was moving all these hard-coded rules to separate
+One of Akim's goal was moving all of these hard-coded rules to separate
@file{Makefile} fragments, so the logic could be centralized in a
@file{Makefile} fragment processor.
@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
@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 / commitdiff