bug-automake
[Top][All Lists]
Advanced

[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





reply via email to

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