Re: not breaking "make" after m4 macros and source files changed

[Stefano Lattarini]

Hello Bruno, and thanks for bringing this up.

On Saturday 02 April 2011, Bruno Haible wrote:
> [CCing the automake list]
> 
> Ralf Wildenhues wrote in
> <http://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00025.html>:
> > > It's that it's unreliable. The autotools
> > > don't cope automatically with .m4 files that have been renamed,
> > 
> > That is simply not true with Automake 1.11 any more.
> > 
> > > m4 macros that have been renamed,
> > 
> > Can you show an example for this?
> > 
> > > conditional use of AC_CONFIG_LINKS when the condition has changed,
> > 
> > I agree that this is currently a problem.  However, removing all links
> > manually is a very cheap operation, also, because re-instating them by
> > 'make' later usually won't cause a rebuild flood as the time stamps of
> > the linked-to file count, which are still old.  IOW, this is easily
> > worked around.
> > 
> > > source .h files that have been renamed or removed,
> > 
> > I would like to see evidence for this as well.
> > 
> > > and so on. Such situations are quite rare when someone works in an 
> > > isolated
> > > project, but become not so rare when people use gnulib.
> > 
> > Please, we should strive to get such issues working when possible.
> 
> OK, let me get more constructive. For which of the following do you have
> test cases in the Automake test suite already, that verify that after
> "./configure" and "make" and some edits in the infrastructure, "make"
> still works as well as "make -k distclean; ./configure; make" would
> have worked:
>
>   - A renamed m4 macro.
>     Before: m4/foo.m4 defines FOO1, configure.ac depends on m4/macros.m4 that
>             invokes FOO1.
>     After:  m4/foo.m4 defines FOO2, configure.ac depends on m4/macros.m4 that
>             invokes FOO2.
> 
>   - A removed m4 file.
>     Before: m4/foo.m4 defines FOO, configure.ac depends on m4/macros.m4 that
>             invokes FOO.
>     After:  m4/foo.m4 is gone, configure.ac depends on m4/macros.m4 that
>             does not invoke FOO any more.
> 
>   - A renamed m4 file.
>     Before: m4/foo1.m4 defines FOO, configure.ac depends on m4/macros.m4 that
>             invokes FOO.
>     After:  m4/foo2.m4 defines FOO, configure.ac depends on m4/macros.m4 that
>             invokes FOO.
> 
>   - A renamed m4 macro in a renamed m4 file.
>     Before: m4/foo1.m4 defines FOO1, configure.ac depends on m4/macros.m4 that
>             invokes FOO1.
>     After:  m4/foo2.m4 defines FOO2, configure.ac depends on m4/macros.m4 that
>             invokes FOO2.
> 
>   - An added AC_SUBST.
>     Before: configure.ac depends on m4/macros.m4 that AC_SUBSTs FOO.
>             lib/foo.h is generated through lib/Makefile, substituting FOO.
>             lib/foo.c includes foo.h and needs to be compiled for 'all'.
>     After:  configure.ac depends on m4/macros.m4 that AC_SUBSTs FOO and BAR.
>             lib/foo.h is generated through lib/Makefile, substituting FOO and 
> BAR.
>             lib/foo.c includes foo.h and needs to be compiled for 'all'.
> 
>   - An added .h file.
>     Before: configure.ac depends on m4/macros.m4 that AC_SUBSTs STDIO_H to 
> empty.
>             lib/stdio.h is generated through lib/Makefile if STDIO_H is 
> non-empty.
>             lib/foo.c includes stdio.h and needs to be compiled for 'all'.
>     After:  configure.ac depends on m4/macros.m4 that AC_SUBSTs STDIO_H to 
> stdio.h.
>             lib/stdio.h is generated through lib/Makefile if STDIO_H is 
> non-empty.
>             lib/foo.c includes stdio.h and needs to be compiled for 'all'.
>     Here you need to check that after "make", lib/stdio.h is present.
> 
>   - A removed .h file.
>     Before: configure.ac depends on m4/macros.m4 that AC_SUBSTs STDIO_H to 
> stdio.h.
>             lib/stdio.h is generated through lib/Makefile if STDIO_H is 
> non-empty.
>             lib/foo.c includes stdio.h and needs to be compiled for 'all'.
>     After:  configure.ac depends on m4/macros.m4 that AC_SUBSTs STDIO_H to 
> empty.
>             lib/stdio.h is generated through lib/Makefile if STDIO_H is 
> non-empty.
>             lib/foo.c includes stdio.h and needs to be compiled for 'all'.
>     Here you need to check that after "make", lib/stdio.h is gone.
> 
> For which of these do we still need to write test cases?
>
We have:

 $ grep -l '\.m4' *.test | xargs grep -l '\$MAKE' | xargs grep -l 'sleep'
 acloca13.test
 acloca14.test
 aclocal6.test
 autohdr3.test
 flavor.test
 makej.test
 missing.test
 missing2.test
 pr8365-remake-timing.test
 remake10a.test
 remake10c.test
 remake4.test
 remake5.test
 remake8a.test
 remake8b.test
 remake9c.test
 remake9d.test
 subdir5.test
 subdir8.test
 version7.test

and a rapid perusing of those files shows that no one of them tests
any of the scenarios described by you.  So we'll need new testcases
for all those scenarios, I fear.

Regards,
   Stefano