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

[Resending, copy sent at 09:09 UTC from h...@ntp.org has not arrived in automake@ archive, though it is in bug-gnulib@ archive.] On Sun, Apr 3, 2011 at 08:22 UTC, Ralf Wildenhues wrote: > * Bruno Haible wrote on Sat, Apr 02, 2011 at 07:08:14PM CEST: >> - A removed .h file. >> Before: configu

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

On Sun, Apr 3, 2011 at 08:22 UTC, Ralf Wildenhues wrote: > * Bruno Haible wrote on Sat, Apr 02, 2011 at 07:08:14PM CEST: >>   - 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

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

Hi Ralf, Stefano, > I'll make amend by writing the new testcases, if you can wait some more > time (maybe a couple of days). Thanks. You can take this as input (I have copyright assignment on file with Automake): > - A renamed m4 macro. > Before: m4/foo.m4 defines FOO1, configure.ac depend

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

Hi Ralf, Bruno, and sorry for my previous sloppy(ish) answer. I'll make amend by writing the new testcases, if you can wait some more time (maybe a couple of days). On Sunday 03 April 2011, Ralf Wildenhues wrote: > Hi Bruno, > > * Bruno Haible wrote on Sat, Apr 02, 2011 at 07:08:14PM CEST: > > O

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

Hi Bruno, * Bruno Haible wrote on Sat, Apr 02, 2011 at 07:08:14PM CEST: > 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

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

Hello Bruno, and thanks for bringing this up. On Saturday 02 April 2011, Bruno Haible wrote: > [CCing the automake list] > > Ralf Wildenhues wrote in > : > > > It's that it's unreliable. The autotools > > > don't cope automatical