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

[Ralf Wildenhues]

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.

>   - 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

>   - 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.

>   - 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.

>   - 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.

>   - 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.

Thanks,
Ralf