Re: Merging 'yacc-work' into master

[Peter Rosin]

Stefano Lattarini skrev 2012-02-12 15:59:
> I have cloned 'master' into a temporary branch 'yl-work-for-master',
> merged master in there, and pushed.  You can find the resulting branch
> here:
> 
>   http://git.savannah.gnu.org/cgit/automake.git/log/?h=yl-work-for-master
> 
> Below are the commit message and the stats of the merge, and attached
> is the (compressed) result of:
> 
>   git diff --stat master yl-work-for-master
> 
> I will merge the 'yl-work-for-master' branch back into master in 72
> hours or so if there is no objection by then.

I read through some of it, and would like to add this patch to the
yacc-work branch.

Cheers,
Peter

From: Peter Rosin <address@hidden>
Date: Mon, 13 Feb 2012 13:47:12 +0100
Subject: [PATCH] news: fix unclear wording and grammaros related to Yacc

* NEWS: Make it clear that it's the derived C code that has
to be non-distributed for it to be removed by "make clean",
not the Yacc/Lex source.  Also fix some grammaros and typos.
---
 NEWS |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 8fae2dd..b4f6a56 100644
--- a/NEWS
+++ b/NEWS
@@ -103,15 +103,15 @@ New in 1.11.0a:
 
 * Changes to Yacc support:
 
-  - C source and header files derived from non-distributed Yacc and/or
+  - Non-distributed C source and header files derived from Yacc and/or
     Lex sources are now removed by a simple "make clean" (while they were
-    previously removed only "make maintainer-clean").
+    previously removed only by "make maintainer-clean").
 
   - Slightly backward-incompatible change, relevant only for use of Yacc
     with C++: the extensions of the header files produced by the Yacc
-    rules are now modelled after extension of the sources corresponding
+    rules are now modelled after the extension of the corresponding
     sources.  For example, yacc files named "foo.y++" and "bar.yy" will
-    produce header files named respectively "foo.h++" and "bar.hh", where
+    produce header files named "foo.h++" and "bar.hh" respectively, where
     they would have previously produced header files named simply "foo.h"
     and "bar.h".  This change offers better compatibility with `bison -o'.
 
-- 
1.7.5.1