[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake 1.7.9 : wrong order of creation config header and stamp fil
From: |
Alexandre Duret-Lutz |
Subject: |
Re: automake 1.7.9 : wrong order of creation config header and stamp file. |
Date: |
Fri, 09 Apr 2004 09:00:43 +0200 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) |
>>> "Carlo" == Carlo Wood <address@hidden> writes:
Carlo> The normal (automake generated) rules for (re)generating config.h, are:
Carlo> config.h: stamp-h1
Carlo> @if test ! -f $@; then \
Carlo> rm -f stamp-h1; \
Carlo> $(MAKE) stamp-h1; \
Carlo> else :; fi
Carlo> stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
Carlo> @rm -f stamp-h1
Carlo> cd $(top_builddir) && $(SHELL) ./config.status config.h
Carlo> This means that when the latter is executed then config.h
Carlo> is generated and thus has a timestamp that is newer than
Carlo> stamp-h1; causing the first rule not to trigger (anymore).
Carlo> In other words, config.h must be NEWER than stamp-h1, normally.
Actually, it doesn't matter. If you look at the rules, you can
see that the first one runs some non-null command only when
`stamp-h1' does not exist, and the second one does not care
about `config.h'. So the ordering between `config.h' and
`stamp-h1' does not matter. This is precisely what we want:
because `config.status' strives not to update `config.h'
needlessly, `stamp-h1' is usually newer that `config.h'.
[...]
Carlo> For example,
Carlo> /usr/src/gtk/eDragon/build>../configure --enable-maintainer-mode
--enable-debug
Carlo> [...]
Carlo> configure: creating ./config.status
Carlo> [...]
Carlo> config.status: creating config.h
Carlo> /usr/src/gtk/eDragon/build>make
Carlo> cd .. && /bin/sh /usr/src/gtk/eDragon/missing --run autoheader
Carlo> touch ../config.h.in
Carlo> cd . && /bin/sh ./config.status config.h
Look at your quote: the first command being run by make is
`autoheader' because `config.h.in' is out of date. This
rebuilds `config.h.in', and that is this update of `config.h.in'
that triggers the second rule above.
In other words, the real problem to investigate is why
`autoheader' is called by make. Running `autoheader' before
running configure is likely to fix that.
[...]
Carlo> I edited autoconf/autoconf.m4f and autoconf/status.m4
Carlo> and moved the block
Carlo> dnl If running for Automake, be ready to perform additional
Carlo> dnl commands to set up the timestamp files.
Carlo> m4_ifdef([_AC_AM_CONFIG_HEADER_HOOK],
Carlo> [_AC_AM_CONFIG_HEADER_HOOK([$ac_file])
Carlo> up to just before
Carlo> # Let's still pretend it is `configure' which instantiates (i.e., don't
That sounds wrong to me because the autoconf code you postpone
will create the destination directory if it does not exist.
The automake hook will fail if it does not.
Carlo> On the other hand - it might be better to change automake,
Carlo> change _AC_AM_CONFIG_HEADER_HOOK to touch [$ac_file]
This would be worse. That whole setup is precisely here to
handle cases where `config.status' decided not to update
`$ac_file'. Changing the timestamp needlessly causes unwanted
rebuilds of the all the objects.
--
Alexandre Duret-Lutz