bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: not breaking "make" after m4 macros and source files changed
Date: Sat, 2 Apr 2011 19:08:14 +0200
User-agent: KMail/1.9.9

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

Bruno
-- 
In memoriam Karol Wojtyla <http://en.wikipedia.org/wiki/Karol_Wojtyla>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]