[PATCH] tests/yaccdry.test ($required): Require bison. (was: Re: More problems with `make -n' in automake-generated rules.)

2010-11-14 Thread Stefano Lattarini
I'm seeing this failure in test yaccdry.test at the Hydra continuous
build system for automake:

 http://hydra.nixos.org/build/745050/log

  FAIL: yaccdry.test (exit: 2) 
   
  /tmp/nix-build-9l5zbyj69kwsr3iyps70a2a5nsnpj7hn-automake-1.11a.drv-0/automake-1.11a/tests:/...
  ++ pwd 
  /tmp/nix-build-9l5zbyj69kwsr3iyps70a2a5nsnpj7hn-automake-1.11a.drv-0/automake-1.11a/tests/yaccdry.dir
   
  + set -e 
  + cat 
  + cat 
  + cat 
  + cat 
  + aclocal-1.11a -Werror 
  + automake-1.11a --foreign -Werror -Wall --add-missing 
  configure.in: installing `./ylwrap' 
  + autoconf 
  + ./configure 
  checking for a BSD-compatible install... /...-coreutils-8.4/bin/install -c 
  checking whether build environment is sane... yes 
  checking for a thread-safe mkdir -p... /...-coreutils-8.4/bin/mkdir -p 
  checking for gawk... gawk 
  checking whether make sets $(MAKE)... yes 
  checking for gcc... gcc 
  checking whether the C compiler works... yes 
  checking for C compiler default output file name... a.out 
  checking for suffix of executables...  
  checking whether we are cross compiling... no 
  checking for suffix of object files... o 
  checking whether we are using the GNU C compiler... yes 
  checking whether gcc accepts -g... yes 
  checking for gcc option to accept ISO C89... none needed 
  checking for style of include used by make... GNU 
  checking dependency style of gcc... gcc3 
  checking for bison... no 
  checking for byacc... no 
  configure: creating ./config.status 
  config.status: creating Makefile 
  config.status: executing depfiles commands 
  + make 
  gcc -DPACKAGE_NAME=\yaccdry\ -DPACKAGE_TARNAME=\yaccdry\ \
  -DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\yaccdry\ 1.0\ \
  -DPACKAGE_BUGREPORT=\\ - DPACKAGE_URL=\\ \
  -DPACKAGE=\yaccdry\ -DVERSION=\1.0\ \
  -I. -g -O2 \
  -MT foo.o -MD -MP -MF .deps/foo.Tpo -c -o foo.o foo.c 
  mv -f .deps/foo.Tpo .deps/foo.Po 
  /bin/sh ./ylwrap parse.y y.tab.c parse.c y.tab.h parse.h y.output 
  parse.output -- yacc -d
  ./ylwrap: line 113: yacc: command not found
  make: *** [parse.c] Error 1 
  + exit_status=2 
  + set +e 
  + cd 
  /tmp/nix-build-9l5zbyj69kwsr3iyps70a2a5nsnpj7hn-automake-1.11a.drv-0/automake-1.11a/tests
   
  + case $exit_status,$keep_testdirs in 
  + test 0 '!=' 0 
  + echo 'yaccdry: exit 2' 
  yaccdry: exit 2 
  + exit 2

OK to apply the attached patch to a temporary bugfix branch to be
then merged into maint?

Regards,
  Stefano
From 279d77d1043a0d5235b88ddba99d05fdc2be96ee Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Mon, 15 Nov 2010 02:12:10 +0100
Subject: [PATCH] tests/yaccdry.test ($required): Require bison.

---
 ChangeLog  |4 
 tests/yaccdry.test |1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6c17cd3..af7e7cd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2010-11-15  Stefano Lattarini  stefano.lattar...@gmail.com
+
+	* tests/yaccdry.test ($required): Require bison.
+
 2010-11-01  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
 	Fix and document rules to not touch the tree with `make -n'.
diff --git a/tests/yaccdry.test b/tests/yaccdry.test
index d11d3fe..d2e7632 100755
--- a/tests/yaccdry.test
+++ b/tests/yaccdry.test
@@ -16,6 +16,7 @@
 
 # Removal recovery rules for headers should not remove files with `make -n'.
 
+required=bison
 . ./defs || Exit 1
 
 set -e
-- 
1.7.1



Re: More problems with `make -n' in automake-generated rules.

2010-11-10 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Mon, Nov 01, 2010 at 10:18:55PM CET:
 Fix and document rules to not touch the tree with `make -n'.
 
 * doc/automake.texi (Multiple Outputs): Document the problem of
 modifications during dry-run execution, propose solution.
 * NEWS: Update.
 * automake.in (lang_vala_finish_target): Split recipe so the
 stamp file is not removed with GNU `make -n'.
 (lang_yacc_target_hook): Separate removal of parser output file
 and header remaking.
 * lib/am/lisp.am ($(am__ELCFILES)): Determine whether -n was
 passed to make, take care not to remove any files in that case.
 * lib/am/remake-hdr.am (%CONFIG_H%): Separate removal of
 %STAMP% file from induced remaking of config header.
 * tests/autohdrdry.test, tests/lispdry.test, tests/yaccdry.test:
 New tests.
 * tests/Makefile.am (TESTS): Update.

This test needed a fixup, as yaccdry requires nonempty $YACC.
Found by the NixOS Hydra, kudos to them!
http://hydra.nixos.org/build/741504

The test could probably also be written without requiring bison
(make -t or so), but I'd prefer to have the setup be realistic,
that's more important than having coverage on every system out there.

Pushed to maint.

Thanks,
Ralf

Fix yaccdry.test failure: require bison.

* tests/yaccdry.test: Require bison.
Found by NixOS Hydra.

diff --git a/tests/yaccdry.test b/tests/yaccdry.test
index d11d3fe..d2e7632 100755
--- a/tests/yaccdry.test
+++ b/tests/yaccdry.test
@@ -16,6 +16,7 @@
 
 # Removal recovery rules for headers should not remove files with `make -n'.
 
+required=bison
 . ./defs || Exit 1
 
 set -e



Re: More problems with `make -n' in automake-generated rules.

2010-11-07 Thread Ralf Wildenhues
* Stefano Lattarini wrote on Sat, Nov 06, 2010 at 08:23:30PM CET:
 On Saturday 06 November 2010, Stefano Lattarini wrote:
  On Saturday 06 November 2010, Ralf Wildenhues wrote:
   * Stefano Lattarini wrote on Sat, Nov 06, 2010 at 05:52:57PM CET:
Hi Ralf, I've just spotted a bug in the patch ...
[...]
... here (missing fi).  It causes a failure in `vala2.test'.

I'll install a fix later if you don't beat me (right now I'm doing other
testing, and prefer not to be sidetracked by this issue).
   
   That's what I get for forgetting one testsuite addition.  Thanks for
   tracking this down, and please push the fix, ideally together with a
   new test
  Is a new test really needed?  After all, I noticed the bug because it
  broke the pre-existing `vala2.test'...

Ouch.  That means I either messed up testing somehow, or pushed an old
version of the patch.  Probably the latter, as I remember fixing a vala
related bug.

 I've gone ahead and comitted the fix without adding a new testcase.
 Please let me know if you still think a testcase addition would be
 valuable, in which case I'll add it in a follow-up patch.

No, in that case it is fine as is.  Thanks.

Cheers,
Ralf



Re: More problems with `make -n' in automake-generated rules.

2010-11-06 Thread Stefano Lattarini
Hi Ralf, I've just spotted a bug in the patch ...

On Monday 01 November 2010, Ralf Wildenhues wrote:
 diff --git a/automake.in b/automake.in
 index cb5fe24..42eff2b 100644
 --- a/automake.in
 +++ b/automake.in
 @@ -6070,11 +6070,11 @@ sub lang_vala_finish_target ($$)
 '--vapi', '--internal-vapi', '--gir')))
   {
 my $headerfile = $flag;
 -   $output_rules .= \$(srcdir)/$headerfile: 
 \$(srcdir)/${derived}_vala.stamp\n.
 - \...@if test -f \$@; then :; else \\\n.
 - \t  rm -f \$(srcdir)/${derived}_vala.stamp; \\\n.
 - \t  \$(am__cd) \$(srcdir)  \$(MAKE) \$(AM_MAKEFLAGS) 
 ${derived}_vala.stamp; \\\n.
 - \tfi\n;
 +   $output_rules .= \$(srcdir)/$headerfile: 
 \$(srcdir)/${derived}_vala.stamp\n
 + . \...@if test -f \$@; then :; else rm -f 
 \$(srcdir)/${derived}_vala.stamp; \n
... here (missing fi).  It causes a failure in `vala2.test'.

I'll install a fix later if you don't beat me (right now I'm doing other
testing, and prefer not to be sidetracked by this issue).

Regards,
Stefano



Re: More problems with `make -n' in automake-generated rules.

2010-11-06 Thread Ralf Wildenhues
Hi Stefano,

* Stefano Lattarini wrote on Sat, Nov 06, 2010 at 05:52:57PM CET:
 Hi Ralf, I've just spotted a bug in the patch ...

  - $output_rules .= \$(srcdir)/$headerfile: 
  \$(srcdir)/${derived}_vala.stamp\n.
  -   \...@if test -f \$@; then :; else \\\n.
  -   \t  rm -f \$(srcdir)/${derived}_vala.stamp; \\\n.
  -   \t  \$(am__cd) \$(srcdir)  \$(MAKE) \$(AM_MAKEFLAGS) 
  ${derived}_vala.stamp; \\\n.
  -   \tfi\n;
  + $output_rules .= \$(srcdir)/$headerfile: 
  \$(srcdir)/${derived}_vala.stamp\n
  +   . \...@if test -f \$@; then :; else rm -f 
  \$(srcdir)/${derived}_vala.stamp; \n
 ... here (missing fi).  It causes a failure in `vala2.test'.
 
 I'll install a fix later if you don't beat me (right now I'm doing other
 testing, and prefer not to be sidetracked by this issue).

That's what I get for forgetting one testsuite addition.  Thanks for
tracking this down, and please push the fix, ideally together with a
new test (but better fixed without than nothing).

Cheers,
Ralf



Re: More problems with `make -n' in automake-generated rules.

2010-11-06 Thread Stefano Lattarini
On Saturday 06 November 2010, Ralf Wildenhues wrote:
 Hi Stefano,
 
 * Stefano Lattarini wrote on Sat, Nov 06, 2010 at 05:52:57PM CET:
  Hi Ralf, I've just spotted a bug in the patch ...
 
   -   $output_rules .= \$(srcdir)/$headerfile: 
   \$(srcdir)/${derived}_vala.stamp\n.
   - \...@if test -f \$@; then :; else \\\n.
   - \t  rm -f \$(srcdir)/${derived}_vala.stamp; \\\n.
   - \t  \$(am__cd) \$(srcdir)  \$(MAKE) \$(AM_MAKEFLAGS) 
   ${derived}_vala.stamp; \\\n.
   - \tfi\n;
   +   $output_rules .= \$(srcdir)/$headerfile: 
   \$(srcdir)/${derived}_vala.stamp\n
   + . \...@if test -f \$@; then :; else rm -f 
   \$(srcdir)/${derived}_vala.stamp; \n
  ... here (missing fi).  It causes a failure in `vala2.test'.
  
  I'll install a fix later if you don't beat me (right now I'm doing other
  testing, and prefer not to be sidetracked by this issue).
 
 That's what I get for forgetting one testsuite addition.  Thanks for
 tracking this down, and please push the fix, ideally together with a
 new test
Is a new test really needed?  After all, I noticed the bug because it
broke the pre-existing `vala2.test'...

Regards,
   Stefano



Re: More problems with `make -n' in automake-generated rules.

2010-11-06 Thread Stefano Lattarini
Hello Ralf.

On Saturday 06 November 2010, Stefano Lattarini wrote:
 On Saturday 06 November 2010, Ralf Wildenhues wrote:
  Hi Stefano,
  
  * Stefano Lattarini wrote on Sat, Nov 06, 2010 at 05:52:57PM CET:
   Hi Ralf, I've just spotted a bug in the patch ...
  
- $output_rules .= \$(srcdir)/$headerfile: 
\$(srcdir)/${derived}_vala.stamp\n.
-   \...@if test -f \$@; then :; else \\\n.
-   \t  rm -f \$(srcdir)/${derived}_vala.stamp; \\\n.
-   \t  \$(am__cd) \$(srcdir)  \$(MAKE) \$(AM_MAKEFLAGS) 
${derived}_vala.stamp; \\\n.
-   \tfi\n;
+ $output_rules .= \$(srcdir)/$headerfile: 
\$(srcdir)/${derived}_vala.stamp\n
+   . \...@if test -f \$@; then :; else rm -f 
\$(srcdir)/${derived}_vala.stamp; \n
   ... here (missing fi).  It causes a failure in `vala2.test'.
   
   I'll install a fix later if you don't beat me (right now I'm doing other
   testing, and prefer not to be sidetracked by this issue).
  
  That's what I get for forgetting one testsuite addition.  Thanks for
  tracking this down, and please push the fix, ideally together with a
  new test
 Is a new test really needed?  After all, I noticed the bug because it
 broke the pre-existing `vala2.test'...
I've gone ahead and comitted the fix without adding a new testcase.
Please let me know if you still think a testcase addition would be
valuable, in which case I'll add it in a follow-up patch.

Regards,
   Stefano



Re: More problems with `make -n' in automake-generated rules.

2010-11-04 Thread Ralf Wildenhues
* Stefano Lattarini wrote on Wed, Nov 03, 2010 at 06:48:16PM CET:
 Hello Ralf.  Again, just a couple of nits w.r.t. the test cases...

Thanks; but I didn't mean to actually commit the second patch
(just in case that wasn't clear).

That said, I'll reply to your comments inline.

 On Monday 01 November 2010, Ralf Wildenhues wrote:
  --- /dev/null
  +++ b/tests/remakedry.test
  @@ -0,0 +1,82 @@

  +# Make sure GNU `make -n' doesn't trigger file updates when Makefile
  +# is out of date.
  +
  +# The subdir rebuilding rules rely on GNU make automatically updating
  +# the makefile and its prerequisites (through am--refresh).
  +required=GNUmake
 Why requiring GNU make here?  After all, if a make implementation does not
 implement automatic Makefile-rebuild rules, it should trivially pass this
 test, and if implements them, it makes sense to run this test on it too.

But that requires me to think about the test again: was this really
meant to test portable code?  The rebuilding rules, esp. the am--refresh
trick, rely on GNU make-specifics, and special-casing some test of it
just because it may or may not happen to trigger the specifics doesn't
seem robust.  I don't want the next small patch to this test cause a
failure for non-GNU make, a failure I'm really not interested in in this
test.

Does that make sense?

  +cat  Makefile.am 'END'
  +SUBDIRS = sub
  +END
  +mkdir sub
  +:  sub/Makefile.am
  +
  +$ACLOCAL
  +$AUTOMAKE
  +$AUTOCONF
  +./configure
  +$MAKE
  +
  +# The toplevel rule is not problematic, as it is not recursive.
  +$sleep
  +touch Makefile.in
  +$sleep
 Is this second sleep really needed?  More instances below.

Definitely is.  I want Makefile to be strictly newer so that ls -1t
is guaranteed to work not because of locale ordering but because of
different time stamps.

  +$MAKE -n Makefile
  +test `ls -1t Makefile Makefile.in | sed 1q` = Makefile.in
 Waht about using here the `is_newest' function provided by `tests/defs'?

That would be a viable alternative that would also allow to ditch the
second sleep, I guess (untested).

  +# Go through contortions to avoid GNU make's first, internal rebuild 
  Makefile
  +# even in dry mode cycle in the recursive (am--refresh) part.
  +(cd sub  $MAKE -n Makefile AM_MAKEFLAGS=-n Makefile)
 I'd add a || Exit 1 here, just to be sure w.r.t. shells with buggy `set -e'.

What bug would you be trying to work around with it?

 One more intance below.
  +test `ls -1t sub/Makefile config.status | sed 1q` = config.status
  +(cd sub  $MAKE Makefile)
  +test `ls -1t sub/Makefile config.status | sed 1q` = sub/Makefile
  +
  +: 

Cheers,
Ralf



Re: More problems with `make -n' in automake-generated rules.

2010-11-04 Thread Stefano Lattarini
On Thursday 04 November 2010, Ralf Wildenhues wrote:
 Hi Stefano,
 
 * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 06:30:34PM CET:
  On Monday 01 November 2010, Ralf Wildenhues wrote:
   I noticed more issues with automake-generated rules and `make -n':
   
   1) The solutions documented in the `Multiple Outputs' node are not safe
   for use with `make -n'.
   
   2) Consequently, the lisp rules are broken, but also the Yacc, Vala, and
   config.h rules in some cases.
   
   3) The rules to update Makefile, but also those to update and
   Makefile.in, are broken in some circumstances, too.
 
   I'm not sure how useful it is to fix (3).  It is not easy as a user to
   get GNU make to not update any of the dependencies of the Makefile file,
   thanks to its remaking feature (info make Remaking Makefiles).  I'll
   reply with a patch for the 'Makefile' rule, but in order to expose that
   bug, you need to use something like this in a subdirectory of a package:
 make -n Makefile AM_MAKEFLAGS=-n Makefile
   
   I don't think users go to this extent just to have `make -n' work, and
   they definitely won't get the above right on the first try; but then the
   rebuild will already have kicked in, making the issue moot for the
   second try.
  FWIW, I agree that (3) is a minor problem.
 
 I'm not going to push the patch for (3), I never intended to.
Oh, I didn't get that.  Sorry.
 
   Before applying this (to maint, probably) I would appreciate if someone
   could look over it to make sure the patch looks sane.  Thanks.
  I didn't spot any obvious error in the meat of the patch.  Just a couple
  of nits w.r.t. the test cases...
 
 I agree with all of your nits for the first patch, and have pushed it
 after fixing them.
 
 Thanks for the review,
 Ralf
Thanks for the patch ;-)

Stefano 



Re: More problems with `make -n' in automake-generated rules.

2010-11-04 Thread Stefano Lattarini
On Thursday 04 November 2010, Ralf Wildenhues wrote:
 * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 06:48:16PM CET:
  Hello Ralf.  Again, just a couple of nits w.r.t. the test cases...
 
 Thanks; but I didn't mean to actually commit the second patch
 (just in case that wasn't clear).
I didn't get that, sorry.  Anyway, why you don't want to commit this second
patch?  While its usefulness is admittedly limited, being a little bit more
correct (even if only theoretically) wouldn't hurt IMHO.  That said, please
notice that I have no strong opionion in this matter, so if you still prefer
not to commit the patch, by any means don't do that.
 
 That said, I'll reply to your comments inline.
 
  On Monday 01 November 2010, Ralf Wildenhues wrote:
   --- /dev/null
   +++ b/tests/remakedry.test
   @@ -0,0 +1,82 @@
 
   +# Make sure GNU `make -n' doesn't trigger file updates when Makefile
   +# is out of date.
   +
   +# The subdir rebuilding rules rely on GNU make automatically updating
   +# the makefile and its prerequisites (through am--refresh).
   +required=GNUmake
  Why requiring GNU make here?  After all, if a make implementation does not
  implement automatic Makefile-rebuild rules, it should trivially pass this
  test, and if implements them, it makes sense to run this test on it too.
 
 But that requires me to think about the test again: was this really
 meant to test portable code?  The rebuilding rules, esp. the am--refresh
 trick, rely on GNU make-specifics, and special-casing some test of it
 just because it may or may not happen to trigger the specifics doesn't
 seem robust.  I don't want the next small patch to this test cause a
 failure for non-GNU make, a failure I'm really not interested in in this
 test.
 
 Does that make sense?
Yes.  I'd still prefer to leave the GNU make requirement out, and add it
back when (and if) the necessity arise, but I can see your point too.
It's mostly a matter of tastes here, and since I have no strong opinion
on the issue, I'm OK with keeping GNU make in $required.

   +cat  Makefile.am 'END'
   +SUBDIRS = sub
   +END
   +mkdir sub
   +:  sub/Makefile.am
   +
   +$ACLOCAL
   +$AUTOMAKE
   +$AUTOCONF
   +./configure
   +$MAKE
   +
   +# The toplevel rule is not problematic, as it is not recursive.
   +$sleep
   +touch Makefile.in
   +$sleep
  Is this second sleep really needed?  More instances below.
 
 Definitely is.  I want Makefile to be strictly newer so that ls -1t
 is guaranteed to work not because of locale ordering but because of
 different time stamps.
Ah, right, I didn't think of that.  Sorry.

   +$MAKE -n Makefile
   +test `ls -1t Makefile Makefile.in | sed 1q` = Makefile.in
  Waht about using here the `is_newest' function provided by `tests/defs'?
 
 That would be a viable alternative that would also allow to ditch the
 second sleep, I guess (untested).
Nice.

   +# Go through contortions to avoid GNU make's first, internal rebuild 
   Makefile
   +# even in dry mode cycle in the recursive (am--refresh) part.
   +(cd sub  $MAKE -n Makefile AM_MAKEFLAGS=-n Makefile)
  I'd add a || Exit 1 here, just to be sure w.r.t. shells with buggy `set 
  -e'.
 
 What bug would you be trying to work around with it?
Not a specific bug, just a potential one (we already know how problematic
`set -e' can be).  Also, notice that I've written I would add, not We
should add ;-) so feel free to ignore the comment if it seems irrelevant
or overly paranoid to you.
 
  One more intance below.
   +test `ls -1t sub/Makefile config.status | sed 1q` = config.status
   +(cd sub  $MAKE Makefile)
   +test `ls -1t sub/Makefile config.status | sed 1q` = sub/Makefile
   +
   +: 
 
 Cheers,
 Ralf
 

Thanks,
   Stefano



Re: More problems with `make -n' in automake-generated rules.

2010-11-04 Thread Stefano Lattarini
On Thursday 04 November 2010, Ralf Wildenhues wrote:
 * Stefano Lattarini wrote on Thu, Nov 04, 2010 at 09:50:08PM CET:
  On Thursday 04 November 2010, Ralf Wildenhues wrote:
   * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 06:48:16PM CET:
Hello Ralf.  Again, just a couple of nits w.r.t. the test cases...
   
   Thanks; but I didn't mean to actually commit the second patch
   (just in case that wasn't clear).
 
  I didn't get that, sorry.  Anyway, why you don't want to commit this second
  patch?
 
 Causes a slowdown without gain for the user.
 
  While its usefulness is admittedly limited, being a little bit more
  correct (even if only theoretically) wouldn't hurt IMHO.
 
 But then there is no argument to not also fix the other configure.am
 rules (which also have problems in even more obscure and hard-to-use
 cases).  I gave up trying to write exposers for them.
OK, agreed.  Fixing this would IMHO be very low priority anyway.  (And
to be honest, I've *never* expected `make -n' to really make a dry-run
if the Makefile is out-of-date, so I *personally* don't even see this
limitation as a problem -- which probably explains why I don't have
strong feelings on this matter).

Regards,
   Stefano



Re: More problems with `make -n' in automake-generated rules.

2010-11-03 Thread Stefano Lattarini
Hi Ralf.  Thanks for these fixes, I really think that make -n should
really be dry-run if possible.

On Monday 01 November 2010, Ralf Wildenhues wrote:
 I noticed more issues with automake-generated rules and `make -n':
 
 1) The solutions documented in the `Multiple Outputs' node are not safe
 for use with `make -n'.
 
 2) Consequently, the lisp rules are broken, but also the Yacc, Vala, and
 config.h rules in some cases.
 
 3) The rules to update Makefile, but also those to update and
 Makefile.in, are broken in some circumstances, too.
 
 The patch below fixes the documentation and addresses (2).  The patch
 doesn't add testsuite coverage for Vala because there are several
 changes pending for this; I'm guessing the code will work differently
 afterwards anyway.
 
 I'm not sure how useful it is to fix (3).  It is not easy as a user to
 get GNU make to not update any of the dependencies of the Makefile file,
 thanks to its remaking feature (info make Remaking Makefiles).  I'll
 reply with a patch for the 'Makefile' rule, but in order to expose that
 bug, you need to use something like this in a subdirectory of a package:
   make -n Makefile AM_MAKEFLAGS=-n Makefile
 
 I don't think users go to this extent just to have `make -n' work, and
 they definitely won't get the above right on the first try; but then the
 rebuild will already have kicked in, making the issue moot for the
 second try.
FWIW, I agree that (3) is a minor problem.
 
 Before applying this (to maint, probably) I would appreciate if someone
 could look over it to make sure the patch looks sane.  Thanks.
I didn't spot any obvious error in the meat of the patch.  Just a couple
of nits w.r.t. the test cases...
 
 Fix and document rules to not touch the tree with `make -n'.
 
 * doc/automake.texi (Multiple Outputs): Document the problem of
 modifications during dry-run execution, propose solution.
 * NEWS: Update.
 * automake.in (lang_vala_finish_target): Split recipe so the
 stamp file is not removed with GNU `make -n'.
 (lang_yacc_target_hook): Separate removal of parser output file
 and header remaking.
 * lib/am/lisp.am ($(am__ELCFILES)): Determine whether -n was
 passed to make, take care not to remove any files in that case.
 * lib/am/remake-hdr.am (%CONFIG_H%): Separate removal of
 %STAMP% file from induced remaking of config header.
 * tests/autohdrdry.test, tests/lispdry.test, tests/yaccdry.test:
 New tests.
 * tests/Makefile.am (TESTS): Update.

 [MEGA-CUT]

 diff --git a/tests/autohdrdry.test b/tests/autohdrdry.test
 new file mode 100755
 index 000..1631005
 --- /dev/null
 +++ b/tests/autohdrdry.test
 @@ -0,0 +1,42 @@
 +#!/bin/sh
 +# Copyright (C) 2010 Free Software Foundation, Inc.
 +#
 +# This program is free software; you can redistribute it and/or modify
 +# it under the terms of the GNU General Public License as published by
 +# the Free Software Foundation; either version 2, or (at your option)
 +# any later version.
 +#
 +# This program is distributed in the hope that it will be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with this program.  If not, see http://www.gnu.org/licenses/.
 +
 +# Removal recovery rules for AC_CONFIG_HEADERS should not remove files
 +# with `make -n'.
 +
 +. ./defs
It should be . ./defs || Exit 1 I guess.
 +
 +set -e
 +
 +cat configure.in 'EOF'
 +AC_PROG_CC
 +AC_CONFIG_HEADERS([config.h])
 +AC_OUTPUT
 +EOF
 +
 +: Makefile.am
 +
 +$ACLOCAL
 +$AUTOCONF
 +$AUTOHEADER
 +$AUTOMAKE
 +
 +./configure
 +$MAKE
 +
 +rm -f config.h
 +$MAKE -n
 +test -f stamp-h1
And also checking that config.h is not there, just to be sure?

 diff --git a/tests/lispdry.test b/tests/lispdry.test
 new file mode 100755
 index 000..9eea752
 --- /dev/null
 +++ b/tests/lispdry.test
 @@ -0,0 +1,62 @@
 +#! /bin/sh
 +# Copyright (C) 2005, 2008, 2010 Free Software Foundation, Inc.
 +#
 +# This program is free software; you can redistribute it and/or modify
 +# it under the terms of the GNU General Public License as published by
 +# the Free Software Foundation; either version 2, or (at your option)
 +# any later version.
 +#
 +# This program is distributed in the hope that it will be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with GNU Automake; see the file COPYING.  If not, write to
 +
 +# Check that `make -n' works with the lisp_LISP recover rule.
 +
 +required='emacs non-root'
 +. ./defs || Exit 1
 +
 +set -e
 +
 +cat  Makefile.am  'EOF'
 +dist_lisp_LISP = am-one.el am-two.el am-three.el
 +EOF
 +
 +cat  

Re: More problems with `make -n' in automake-generated rules.

2010-11-03 Thread Stefano Lattarini
Hello Ralf.  Again, just a couple of nits w.r.t. the test cases...

On Monday 01 November 2010, Ralf Wildenhues wrote:
 * Ralf Wildenhues wrote on Mon, Nov 01, 2010 at 10:18:55PM CET:
  3) The rules to update Makefile, but also those to update and
  Makefile.in, are broken in some circumstances, too.
 [...]
  I'm not sure how useful it is to fix (3).  It is not easy as a user to
  get GNU make to not update any of the dependencies of the Makefile file,
  thanks to its remaking feature (info make Remaking Makefiles).  I'll
  reply with a patch for the 'Makefile' rule, but in order to expose that
  bug, you need to use something like this in a subdirectory of a package:
make -n Makefile AM_MAKEFLAGS=-n Makefile
  
  I don't think users go to this extent just to have `make -n' work, and
  they definitely won't get the above right on the first try; but then the
  rebuild will already have kicked in, making the issue moot for the
  second try.
 
 Here it is.
 
 Cheers,
 Ralf
 
 Fix GNU `make -n Makefile' in subdirs to not touch the tree.
 
 * lib/am/configure.am (%MAKEFILE%): Split rule in nonrecursive
 and possibly-recursive parts, for GNU `make -n'.
 * tests/remakedry.test: New test.
 * tests/Makefile.am (TESTS): Update.
 * NEWS: Update.
 
 diff --git a/NEWS b/NEWS
 index 6bc0d6f..76e6543 100644
 --- a/NEWS
 +++ b/NEWS
 @@ -48,7 +48,7 @@ Bugs fixed in 1.11.0a:
  
- Rules generated by Automake now try harder to not change any files when
  `make -n' is invoked.  Fixes include compilation of Emacs Lisp, Vala, or
 -Yacc source files and the rule to update config.h.
 +Yacc source files and the rules to update config.h and a subdir Makefile.
  
  New in 1.11:
  
 diff --git a/lib/am/configure.am b/lib/am/configure.am
 index e9299d6..c10b377 100644
 --- a/lib/am/configure.am
 +++ b/lib/am/configure.am
 @@ -1,5 +1,5 @@
  ## automake - create Makefile.in from Makefile.am
 -## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009  Free
 +## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010 Free
  ## Software Foundation, Inc.
  
  ## This program is free software; you can redistribute it and/or modify
 @@ -75,12 +75,16 @@ endif %?TOPDIR_P%
  ?TOPDIR_P?   echo ' $(SHELL) ./config.status'; \
  ?TOPDIR_P?   $(SHELL) ./config.status;; \
  ?!TOPDIR_P?  cd $(top_builddir)  $(MAKE) $(AM_MAKEFLAGS) am--refresh;; 
 \
 + esac
 +## Split the nonrecursive part off, so GNU `make -n' will not execute it.
 + @case '$?' in \
 +   *config.status*) ;;\
 *) \
  ## FIXME: $(am__depfiles_maybe) lets us re-run the rule to create the
  ## .P files.  Ideally we wouldn't have to do this by hand.
   echo ' cd $(top_builddir)  $(SHELL) ./config.status 
 %CONFIG-MAKEFILE% $(am__depfiles_maybe)'; \
   cd $(top_builddir)  $(SHELL) ./config.status %CONFIG-MAKEFILE% 
 $(am__depfiles_maybe);; \
 - esac;
 + esac
  
  DIST_COMMON += %MAKEFILE-AM%
  
 diff --git a/tests/Makefile.am b/tests/Makefile.am
 index 9c81564..a9aca1e 100644
 --- a/tests/Makefile.am
 +++ b/tests/Makefile.am
 @@ -619,6 +619,7 @@ remake4.test \
  remake5.test \
  remake6.test \
  remake7.test \
 +remakedry.test \
  regex.test \
  req.test \
  reqd.test \
 diff --git a/tests/remakedry.test b/tests/remakedry.test
 new file mode 100755
 index 000..dab46f3
 --- /dev/null
 +++ b/tests/remakedry.test
 @@ -0,0 +1,82 @@
 +#! /bin/sh
 +# Copyright (C) 2010 Free Software Foundation, Inc.
 +#
 +# This program is free software; you can redistribute it and/or modify
 +# it under the terms of the GNU General Public License as published by
 +# the Free Software Foundation; either version 2, or (at your option)
 +# any later version.
 +#
 +# This program is distributed in the hope that it will be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with this program.  If not, see http://www.gnu.org/licenses/.
 +
 +# Make sure GNU `make -n' doesn't trigger file updates when Makefile
 +# is out of date.
 +
 +# The subdir rebuilding rules rely on GNU make automatically updating
 +# the makefile and its prerequisites (through am--refresh).
 +required=GNUmake
Why requiring GNU make here?  After all, if a make implementation does not
implement automatic Makefile-rebuild rules, it should trivially pass this
test, and if implements them, it makes sense to run this test on it too.
 +. ./defs || Exit 1
 +
 +set -e
 +
 +cat  configure.in  'END'
 +AC_CONFIG_FILES([sub/Makefile])
 +AC_OUTPUT
 +END
 +
 +cat  Makefile.am 'END'
 +SUBDIRS = sub
 +END
 +mkdir sub
 +:  sub/Makefile.am
 +
 +$ACLOCAL
 +$AUTOMAKE
 +$AUTOCONF
 +./configure
 +$MAKE
 +
 +# The toplevel rule is not problematic, as it is not recursive.
 +$sleep
 +touch Makefile.in
 +$sleep
Is this second sleep 

Re: More problems with `make -n' in automake-generated rules.

2010-11-01 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Mon, Nov 01, 2010 at 10:18:55PM CET:
 3) The rules to update Makefile, but also those to update and
 Makefile.in, are broken in some circumstances, too.
[...]
 I'm not sure how useful it is to fix (3).  It is not easy as a user to
 get GNU make to not update any of the dependencies of the Makefile file,
 thanks to its remaking feature (info make Remaking Makefiles).  I'll
 reply with a patch for the 'Makefile' rule, but in order to expose that
 bug, you need to use something like this in a subdirectory of a package:
   make -n Makefile AM_MAKEFLAGS=-n Makefile
 
 I don't think users go to this extent just to have `make -n' work, and
 they definitely won't get the above right on the first try; but then the
 rebuild will already have kicked in, making the issue moot for the
 second try.

Here it is.

Cheers,
Ralf

Fix GNU `make -n Makefile' in subdirs to not touch the tree.

* lib/am/configure.am (%MAKEFILE%): Split rule in nonrecursive
and possibly-recursive parts, for GNU `make -n'.
* tests/remakedry.test: New test.
* tests/Makefile.am (TESTS): Update.
* NEWS: Update.

diff --git a/NEWS b/NEWS
index 6bc0d6f..76e6543 100644
--- a/NEWS
+++ b/NEWS
@@ -48,7 +48,7 @@ Bugs fixed in 1.11.0a:
 
   - Rules generated by Automake now try harder to not change any files when
 `make -n' is invoked.  Fixes include compilation of Emacs Lisp, Vala, or
-Yacc source files and the rule to update config.h.
+Yacc source files and the rules to update config.h and a subdir Makefile.
 
 New in 1.11:
 
diff --git a/lib/am/configure.am b/lib/am/configure.am
index e9299d6..c10b377 100644
--- a/lib/am/configure.am
+++ b/lib/am/configure.am
@@ -1,5 +1,5 @@
 ## automake - create Makefile.in from Makefile.am
-## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009  Free
+## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010 Free
 ## Software Foundation, Inc.
 
 ## This program is free software; you can redistribute it and/or modify
@@ -75,12 +75,16 @@ endif %?TOPDIR_P%
 ?TOPDIR_P? echo ' $(SHELL) ./config.status'; \
 ?TOPDIR_P? $(SHELL) ./config.status;; \
 ?!TOPDIR_P?cd $(top_builddir)  $(MAKE) $(AM_MAKEFLAGS) am--refresh;; 
\
+   esac
+## Split the nonrecursive part off, so GNU `make -n' will not execute it.
+   @case '$?' in \
+ *config.status*) ;;\
  *) \
 ## FIXME: $(am__depfiles_maybe) lets us re-run the rule to create the
 ## .P files.  Ideally we wouldn't have to do this by hand.
echo ' cd $(top_builddir)  $(SHELL) ./config.status 
%CONFIG-MAKEFILE% $(am__depfiles_maybe)'; \
cd $(top_builddir)  $(SHELL) ./config.status %CONFIG-MAKEFILE% 
$(am__depfiles_maybe);; \
-   esac;
+   esac
 
 DIST_COMMON += %MAKEFILE-AM%
 
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 9c81564..a9aca1e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -619,6 +619,7 @@ remake4.test \
 remake5.test \
 remake6.test \
 remake7.test \
+remakedry.test \
 regex.test \
 req.test \
 reqd.test \
diff --git a/tests/remakedry.test b/tests/remakedry.test
new file mode 100755
index 000..dab46f3
--- /dev/null
+++ b/tests/remakedry.test
@@ -0,0 +1,82 @@
+#! /bin/sh
+# Copyright (C) 2010 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see http://www.gnu.org/licenses/.
+
+# Make sure GNU `make -n' doesn't trigger file updates when Makefile
+# is out of date.
+
+# The subdir rebuilding rules rely on GNU make automatically updating
+# the makefile and its prerequisites (through am--refresh).
+required=GNUmake
+. ./defs || Exit 1
+
+set -e
+
+cat  configure.in  'END'
+AC_CONFIG_FILES([sub/Makefile])
+AC_OUTPUT
+END
+
+cat  Makefile.am 'END'
+SUBDIRS = sub
+END
+mkdir sub
+:  sub/Makefile.am
+
+$ACLOCAL
+$AUTOMAKE
+$AUTOCONF
+./configure
+$MAKE
+
+# The toplevel rule is not problematic, as it is not recursive.
+$sleep
+touch Makefile.in
+$sleep
+$MAKE -n Makefile
+test `ls -1t Makefile Makefile.in | sed 1q` = Makefile.in
+$MAKE Makefile
+test `ls -1t Makefile Makefile.in | sed 1q` = Makefile
+
+$sleep
+touch config.status
+$sleep
+$MAKE -n Makefile
+test `ls -1t Makefile config.status | sed 1q` = config.status
+$MAKE Makefile
+test `ls -1t Makefile config.status | sed 1q` = Makefile
+
+# The subdir rules are fixed by separating the recursive part from the rest.
+cd sub
+$sleep
+touch Makefile.in
+$sleep
+$MAKE -n