[Automake-commit] [SCM] GNU Automake branch, master, updated. Release-1-10-128-g10386c6

[Ralf Wildenhues]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Automake".

http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=10386c6542d677bdff6500d4f326ab2d22c550a3

The branch, master has been updated
       via  10386c6542d677bdff6500d4f326ab2d22c550a3 (commit)
      from  6489b1bc103459ffd26f36ba17224a746fc6f5e4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 10386c6542d677bdff6500d4f326ab2d22c550a3
Author: Reuben Thomas <address@hidden>
Date:   Wed Feb 27 07:53:02 2008 +0100

    * doc/automake.texi (wildcards): Improve "Why doesn't Automake
    support wildcards" node's English and sense.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog         |    5 +++++
 doc/automake.texi |   43 +++++++++++++++++++------------------------
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 748d60c..eac06de 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2008-02-27  Reuben Thomas  <address@hidden>
+
+       * doc/automake.texi (wildcards): Improve "Why doesn't Automake
+       support wildcards" node's English and sense.
+
 2008-02-23  Ralf Wildenhues  <address@hidden>
 
        * lib/am/check.am (check-TESTS): In the case patterns for
diff --git a/doc/automake.texi b/doc/automake.texi
index c0ace40..2c5dcfa 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -9841,10 +9841,10 @@ version of the tools.
 @section Why doesn't Automake support wildcards?
 @cindex wildcards
 
-Developers are lazy.  They often would like to use wildcards in
address@hidden, so they don't need to remember they have to
-update @file{Makefile.am}s every time they add, delete, or rename a
-file.
+Developers are lazy.  They would often like to use wildcards in
address@hidden, so that they would not need to remember to
+update @file{Makefile.am}s every time they add, delete, or rename
+a file.
 
 There are several objections to this:
 @itemize
@@ -9858,27 +9858,22 @@ because you forgot to add a file in @file{Makefile.am}, 
it will help
 you remember to @samp{cvs add} it.
 
 @item
-Using wildcards makes easy to distribute files by mistake.  For
+Using wildcards makes it easy to distribute files by mistake.  For
 instance, some code a developer is experimenting with (a test case,
-say) but that should not be part of the distribution.
+say) that should not be part of the distribution.
 
 @item
 Using wildcards it's easy to omit some files by mistake.  For
-instance, one developer creates a new file, uses it at many places,
-but forget to commit it.  Another developer then checkout the
-incomplete project and is able to run `make dist' successfully,
-even though a file is missing.
-
address@hidden
-Listing files, you control *exactly* what you distribute.
-If some file that should be distributed is missing from your
-tree, @samp{make dist} will complain.  Besides, you don't distribute
-more than what you listed.
+instance, one developer creates a new file, uses it in many places,
+but forgets to commit it.  Another developer then checks out the
+incomplete project and is able to run @samp{make dist} successfully,
+even though a file is missing. By listing files, @samp{make dist}
address@hidden complain.
 
 @item
-Finally it's really hard to @file{forget} adding a file to
address@hidden, because if you don't add it, it doesn't get
-compiled nor installed, so you can't even test it.
+Finally, it's really hard to @emph{forget} to add a file to
address@hidden: files that are not listed in @file{Makefile.am} are
+not compiled or installed, so you can't even test them.
 @end itemize
 
 Still, these are philosophical objections, and as such you may disagree,
@@ -9891,16 +9886,16 @@ 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.
-Resulting @file{Makefile.in}s would be portable since they would
+The resulting @file{Makefile.in}s would be portable since they would
 list all files and not use @samp{$(wildcard ...)}.  However that
-means developers need to remember they must run @command{automake} each
+means developers would need to remember to run @command{automake} each
 time they add, delete, or rename files.
 
-Compared to editing @file{Makefile.am}, this is really little win.  Sure,
+Compared to editing @file{Makefile.am}, this is a very small gain.  Sure,
 it's easier and faster to type @samp{automake; make} than to type
 @samp{emacs Makefile.am; make}.  But nobody bothered enough to write a
-patch add support for this syntax.  Some people use scripts to
-generated file lists in @file{Makefile.am} or in separate
+patch to add support for this syntax.  Some people use scripts to
+generate file lists in @file{Makefile.am} or in separate
 @file{Makefile} fragments.
 
 Even if you don't care about portability, and are tempted to use


hooks/post-receive
--
GNU Automake