patch: Makefile.in in subdir not generated

[Ilya N. Golubev]

Described what is fixing here in  posted to <[EMAIL PROTECTED]> on
generated> (<[EMAIL PROTECTED]>).

Patched 1.10.1 as follows.

* lib/am/configure.am (%MAKEFILE-IN%): Fixed `exit'ing before
invoking `$(AUTOMAKE)' if prerequisite other then
`Makefile.am' is newer.  Borrowed invocation of recursive
`make' and handling its exit codes from commands generated by
automake for other recursive targets.  Added elimination of
duplicate `$(AUTOMAKE)' invocation.

--- lib/am/configure.am 2008-01-22 01:11:41 +0300
+++ lib/am/configure.am 2008-08-20 22:34:58 +0400
@@ -37,20 +37,37 @@
 ## Makefile.in are to be updated; it is then more efficient to run
 ## automake on all the Makefiles at once.  It also allow Automake to be
 ## run for newly added directories.
-   @for dep in $?; do \
+   @failcom='exit 1'; \
+   for f in x $$MAKEFLAGS; do \
+ case $$f in \
+   *=* | --[!k]*);; \
+   *k*) failcom='fail=yes';; \
+ esac; \
+   done; \
+   am_refreshed=; \
+   for dep in $?; do \
  case '$(am__configure_deps)' in \
*$$dep*) \
+ if [ ! "$$am_refreshed" ];then \
 ?TOPDIR_P?   echo ' cd $(srcdir) && $(AUTOMAKE) --%STRICTNESS% 
%USE-DEPS%'; \
+   ( \
 ?TOPDIR_P?   cd $(srcdir) && $(AUTOMAKE) --%STRICTNESS% %USE-DEPS% \
 ?!TOPDIR_P?  cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh 
\
-   && exit 0; \
- exit 1;; \
+   ) \
+   || eval $$failcom; \
+   am_refreshed=1; \
+ else :;fi;; \
  esac; \
done; \
 ## Otherwise, rebuild only this file.
echo ' cd $(top_srcdir) && $(AUTOMAKE) --%STRICTNESS% %USE-DEPS% 
%MAKEFILE-AM-SOURCES%'; \
-   cd $(top_srcdir) && \
- $(AUTOMAKE) --%STRICTNESS% %USE-DEPS% %MAKEFILE-AM-SOURCES%
+?TOPDIR_P? if [ ! "$$am_refreshed" ];then \
+   { cd $(top_srcdir) && \
+ $(AUTOMAKE) --%STRICTNESS% %USE-DEPS% %MAKEFILE-AM-SOURCES%; \
+   } || exit 1; \
+?TOPDIR_P? am_refreshed=1; \
+?TOPDIR_P? else :;fi; \
+   test -z "$$fail"
 
 ## Ensure that GNU make doesn't remove Makefile if ./config.status (below)
 ## is interrupted.  Otherwise, the user would need to know to rerun

Re: patch: Makefile.in in subdir not generated

[Ralf Wildenhues]

Hello Ilya,

Continuing the discussion started here:

Please do not start a new thread when replying, thank you.

* Ilya N. Golubev wrote on Wed, Aug 20, 2008 at 08:43:53PM CEST:
> Described what is fixing here in  generated> posted to <[EMAIL PROTECTED]> on
> generated> (<[EMAIL PROTECTED]>).

OK, the situation is as follows: if a subdir/Makefile.in has been
removed, then the rebuild rules don't regenerate it correctly.

This is caused by the following: when subdir/Makefile.in is missing,
the rule for $(srcdir)/Makefile.in in subdir/Makefile has $? set to
all of $(am__configure_deps).  The current logic is that, if any
prerequisite is from $(am__configure_deps), then we just remake top
level target am--refresh.  This relies on the notion that, if
subdir/Makefile.in is out of date wrt. configure dependencies, then
toplevel Makefile.in should be as well, causing a complete rerun of
all autotools.

That logic is wrong in this case: for the toplevel Makefile, everything
is up to date.

> Patched 1.10.1 as follows.

> * lib/am/configure.am (%MAKEFILE-IN%): Fixed `exit'ing before
> invoking `$(AUTOMAKE)' if prerequisite other then
> `Makefile.am' is newer.  Borrowed invocation of recursive
> `make' and handling its exit codes from commands generated by
> automake for other recursive targets.  Added elimination of
> duplicate `$(AUTOMAKE)' invocation.

Thank you for your proposed patch.  It's a good starting point.
However, it causes duplicate automake reruns in the common case
where toplevel Makefile.am is updated.  Also, it lacks a test case.

Further, I'm not sure wheter -k should have an impact on the rebuilding
rules of prerequisites of `Makefile'.  Here's why it might be dangerous:
When some Makefile.in is out of date, and the rule rebuilding it were
destined to fail for some reason, and you run "make -k dist", then your
change will let the 'dist' target succeed, AFAICS.  But that would let
the wrong Makefile.in end up in the tarball.

I've pushed the patch below to master, and put you in THANKS (not shown,
neither any regenerated files).  The first test ensures that rebuilding
works for Makefile.in's in the common cases (updated Makefile.am, or
removed Makefile.in), and that automake is never called more than once
for each case.  The second case ensures that 'make' fails when any
rebuilding rule would fail.

I'm still pondering whether to put this in branch-1-10 as well.

Cheers, and thanks again,
Ralf

2008-08-22  Ralf Wildenhues  <[EMAIL PROTECTED]>

Fix rebuilding of removed subdir/Makefile.in files.
* lib/am/configure.am (%MAKEFILE-IN%) [?!TOPDIR_P?]: If
subdir/Makefile.in was removed, am--refresh would not update
it.  Fix up for it by running the per-directory rebuild rule.
* tests/remake6.test, tests/remake7.test: New tests.
* tests/Makefile.am: Adjust.
* NEWS, THANKS: Update.
Report and initial patch by Ilya N. Golubev.

diff --git a/NEWS b/NEWS
index 181ba05..bd1f369 100644
--- a/NEWS
+++ b/NEWS
@@ -55,6 +55,9 @@ New in 1.10a:
 stub rules.  This allows `make' to trigger a rerun of `aclocal'
 also if some previously needed macro file has been removed.
 
+  - Rebuild rules now also work for a removed `subdir/Makefile.in' in
+an otherwise up to date tree.
+
   - The `color-tests' option causes colored test result output on terminals.
 
   - New prefix `notrans_' for manpages which should not be transformed
diff --git a/lib/am/configure.am b/lib/am/configure.am
index 879f837..4623f41 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  Free Software
+## Copyright (C) 2001, 2002, 2003, 2004, 2006, 2007, 2008  Free Software
 ## Foundation, Inc.
 
 ## This program is free software; you can redistribute it and/or modify
@@ -41,8 +41,13 @@ endif %?TOPDIR_P%
*$$dep*) \
 ?TOPDIR_P?   echo ' cd $(srcdir) && $(AUTOMAKE) --%STRICTNESS% 
%USE-DEPS%'; \
 ?TOPDIR_P?   cd $(srcdir) && $(AUTOMAKE) --%STRICTNESS% %USE-DEPS% \
-?!TOPDIR_P?  cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh 
\
-   && exit 0; \
+?TOPDIR_P? && exit 0; \
+?!TOPDIR_P?  ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) 
am--refresh ) \
+## If on the other hand, subdir/Makefile.in has been removed, then toplevel
+## am--refresh will not be aware of any need to run.  We still invoke it
+## due to $? listing all prerequisites.  Fix up for it by running the rebuild
+## rule for this file only, below.
+?!TOPDIR_P?&& { if test -f $@; then exit 0; else break; fi; }; \
  exit 1;; \
  esac; \
done; \
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 45624af..1e19657 100644
--- a/tests/Makefile.am
+++ b/tests/Makefil

Re: patch: Makefile.in in subdir not generated

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Fri, Aug 22, 2008 at 02:57:50PM CEST:
> I'm still pondering whether to put this in branch-1-10 as well.

I think this is safe enough, I've pulled that to branch-1-10
(including the THANKS name fix, of course).

Cheers,
Ralf

> 2008-08-22  Ralf Wildenhues  <[EMAIL PROTECTED]>
> 
>   Fix rebuilding of removed subdir/Makefile.in files.
>   * lib/am/configure.am (%MAKEFILE-IN%) [?!TOPDIR_P?]: If
>   subdir/Makefile.in was removed, am--refresh would not update
>   it.  Fix up for it by running the per-directory rebuild rule.
>   * tests/remake6.test, tests/remake7.test: New tests.
>   * tests/Makefile.am: Adjust.
>   * NEWS, THANKS: Update.
>   Report and initial patch by Ilya N. Golubev.

vanity patch [Re: patch: Makefile.in in subdir not generated]

[Ilya N. Golubev]

> put you in THANKS

Looks like that file is in `utf-8', not restricted to ascii or iso
8859-1, unlike name that is normally put in `From:' field of my
messages (including this one) to english speaking lists, fora.  So
suggesting to change the name there (for <[EMAIL PROTECTED]>) to one in my
native language, script:

Илья Н. Голубев

Thanks in advance.

duplicate automake runs? [patch: Makefile.in in subdir not generated]

[Ilya N. Golubev]

> causes duplicate automake reruns in the common case
> where toplevel Makefile.am is updated.

Explicitly tried avoid that, and stated that in change log entry:

> Added elimination of
> duplicate `$(AUTOMAKE)' invocation.

Even if that still happens, would rather allow for that.  For automake
it is not considered better to be broken than to be slow, is it?

Re: duplicate automake runs? [patch: Makefile.in in subdir not generated]

[Ralf Wildenhues]

Hello Ilya,

* Ilya N. Golubev wrote on Thu, Aug 28, 2008 at 05:40:03PM CEST:
> > causes duplicate automake reruns in the common case
> > where toplevel Makefile.am is updated.
> 
> Explicitly tried avoid that, and stated that in change log entry:
> 
> > Added elimination of
> > duplicate `$(AUTOMAKE)' invocation.

Except my testing showed that your patch doesn't always avoid it.
That's why I wrote the test case.  Please try the testcase with
your patch, and you will see that it fails.  If it doesn't fail,
then I would like to see VERBOSE=yes output of the succeeding test.

> Even if that still happens, would rather allow for that.  For automake
> it is not considered better to be broken than to be slow, is it?

Of course slow is better than broken.  However, as far as I can see,
my patch fixes the failure for good, *and* avoids duplicate automake
reruns.  Best of both worlds!  :-)  Or do you see any issue with it?

Thanks,
Ralf