[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: suggested rule for remaking config.h is wrong
From: |
Eric Blake |
Subject: |
Re: suggested rule for remaking config.h is wrong |
Date: |
Tue, 23 Apr 2013 21:53:57 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 |
On 04/23/2013 09:18 PM, Peter Eisentraut wrote:
> In the manual section "Automatic Remaking", the following rule is
> suggested:
>
> config.h: stamp-h
> stamp-h: config.h.in config.status
> ./config.status
>
> This actually doesn't work so well. It should be
>
> config.h: stamp-h ;
> stamp-h: config.h.in config.status
> ./config.status
Wow - I've been hunting for this very bug for 48 hours now due to an
off-list bug report!
I can definitely confirm that with no recipe, make -d reports the
following on the first run:
Prerequisite `stamp-h' is older than target `config.h'.
No recipe for `config.h' and no prerequisites actually changed.
No need to remake target `config.h'.
and only on the second run does it change its mind:
Prerequisite `stamp-h' is newer than target `config.h'.
Must remake target `config.h'.
Successfully remade target file `config.h'.
Meanwhile, adding the empty recipe (via the trailing semicolon) forces
make to always behave as in the second run pre-patch.
>
> If you look at the makefiles generated by Automake, it agrees.
Well, the file I looked at has a lot more than an empty recipe:
config.h: stamp-h1
@if test ! -f $@; then rm -f stamp-h1; else :; fi
@if test ! -f $@; then $(MAKE) $(AM_MAKEFLAGS) stamp-h1; else :; fi
stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
@rm -f stamp-h1
cd $(top_builddir) && $(SHELL) ./config.status config.h
$(srcdir)/config.h.in: $(am__configure_deps)
($(am__cd) $(top_srcdir) && $(AUTOHEADER))
rm -f stamp-h1
touch $@
but the point remains that automake is not generating an empty recipe file.
>
> This is with GNU Make 3.81.
My testing was with make 3.82.
>
> The rule for config.h.in: stamp-h.in is probably similarly affected, but
> I don't have verification for that.
>
Indeed possible; should I go ahead and suggest a semicolon at both sites
in the manual without waiting for confirmation of whether it makes a
difference?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature