[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: not breaking "make" after m4 macros and source files changed
From: |
Stefano Lattarini |
Subject: |
Re: not breaking "make" after m4 macros and source files changed |
Date: |
Sun, 3 Apr 2011 10:12:13 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
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