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

[Stefano Lattarini]

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:
> > 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.
> 
> automake/tests/aclocal5.test and
> automake/tests/aclocal6.test come close.
>
But a new test wouldn't hurt, would it?

> >   - 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.
> 
> automake/tests/acloca22.test
>
You're perfectly right, sorry for missing that.

> >   - 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.
> 
> These two could use a test.
>
OK.

> >   - 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'.
> 
> This is pretty much an issue with the rule generating lib/foo.h needing
> to depend on config.status, so not primarily an Automake issue.  The
> fact that config.status is regenerated when a macro is updated in some
> way, is exercised in several tests in the Automake testsuite.
>
IMHO, having a testcase about this could be useful anway (although not strictly
required), to show that Automake rebuild rules really work in a real use case.

> >   - 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.
> 
> Likewise.  Since here, automake's dependency tracking is involved, a
> test would be good.
>
OK.

> >   - 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.
> 
> This is a case that doesn't currently work, as nothing causes
> lib/stdio.h to be removed. It is not yet clear to me where to
> stick those semantics sanely.
>
I will wait for more input about this.

Regards,
  Stefano