Thread: pgsql/src (Makefile.global.in)
Date: Friday, December 29, 2000 @ 15:39:06
Author: tgl
Update of /home/projects/pgsql/cvsroot/pgsql/src
from hub.org:/home/projects/pgsql/tmp/cvs-serv55162/src
Modified Files:
Makefile.global.in
----------------------------- Log Message -----------------------------
stamp-h needs to be made by config.status, not elsewhere, per recipe in
Autoconf manual. In particular, touching it before creating config.status
is guaranteed to lose.
tgl@postgresql.org writes: > stamp-h needs to be made by config.status, not elsewhere, per recipe in > Autoconf manual. The recipe in the Autoconf manual is broken. Assume that config.status has been updated to be newer than config.h. Chances are that it is also newer than Makefile.global. (Possibly because your last cvs update fetched a new configure.) Then the make run will first execute config.status to update Makefile.global, which will also run the extra commands in the second argument of AC_OUTPUT. Thus, the stamp file has been updated without any action taking place on config.h*. (This is a very real scenario. I spent quite a bit of time figuring out why initdb in the regression test would fail after the version upgrade to 7.1beta1. (So I guess the version cross-checking in initdb does work. :-) ) The makefiles already got the new version (and hence the shells scripts), but config.h didn't (and therefore not the C programs).) > In particular, touching it before creating config.status is guaranteed > to lose. Exactly why? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> The recipe in the Autoconf manual is broken.
Possibly, but the way you were doing it was definitely broken.
> Assume that config.status has been updated to be newer than config.h.
> Chances are that it is also newer than Makefile.global. (Possibly because
> your last cvs update fetched a new configure.) Then the make run will
> first execute config.status to update Makefile.global, which will also run
> the extra commands in the second argument of AC_OUTPUT. Thus, the stamp
> file has been updated without any action taking place on config.h*.
Huh? There is only one config.status, and it'll update all its output
files whenever it runs. I don't see the issue.
>> In particular, touching it before creating config.status is guaranteed
>> to lose.
> Exactly why?
Excess runs of config.status. stamp-h has to be touched after making
config.status, not before. Also, although this may be a third-order
consideration, I direct your attention to configure's --no-create
option...
regards, tom lane
Tom Lane writes:
> Huh? There is only one config.status, and it'll update all its output
> files whenever it runs. I don't see the issue.
The rules in the makefiles cause config.status to only update the file
that triggered the rule. E.g.,
GNUmakefile: GNUmakefile.in $(top_builddir)/config.status
CONFIG_FILES=$@ CONFIG_HEADERS= ./config.status
(Yes, this interface is incredibly stupid.)
> >> In particular, touching it before creating config.status is guaranteed
> >> to lose.
>
> > Exactly why?
>
> Excess runs of config.status. stamp-h has to be touched after making
> config.status, not before.
Ok, now I see it. I guess we'll have to go back to forcing a touch of
config.h after config.status runs in order to get this to work properly.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
>> Huh? There is only one config.status, and it'll update all its output
>> files whenever it runs. I don't see the issue.
> The rules in the makefiles cause config.status to only update the file
> that triggered the rule. E.g.,
> GNUmakefile: GNUmakefile.in $(top_builddir)/config.status
> CONFIG_FILES=$@ CONFIG_HEADERS= ./config.status
> (Yes, this interface is incredibly stupid.)
Uh, why don't we just make it generate all its output files each time?
regards, tom lane
Tom Lane writes: > > The rules in the makefiles cause config.status to only update the file > > that triggered the rule. E.g., > > > GNUmakefile: GNUmakefile.in $(top_builddir)/config.status > > CONFIG_FILES=$@ CONFIG_HEADERS= ./config.status > > > (Yes, this interface is incredibly stupid.) > > Uh, why don't we just make it generate all its output files each time? Because the commands in a rule should generally only update the target file. Say I change backend/port/Makefile.in, then run make, then config.status should not update Makefile.global, because that will trigger a bunch of other rules (e.g., initdb) that I didn't ask for. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
>> Uh, why don't we just make it generate all its output files each time?
> Because the commands in a rule should generally only update the target
> file.
If you insist ...
Perhaps the answer is to treat stamp-h as a real output file (ie,
generated from a stamp-h.in file) rather than hacking it into place
as an AC_OUTPUT extra command. It looks to me like config.status
only does the keep-the-old-timestamp bit for CONFIG_HEADERS files,
not CONFIG_FILES files, so classifying stamp-h as the latter kind
would make things work.
regards, tom lane
Tom Lane writes: > Perhaps the answer is to treat stamp-h as a real output file (ie, > generated from a stamp-h.in file) rather than hacking it into place > as an AC_OUTPUT extra command. It looks to me like config.status > only does the keep-the-old-timestamp bit for CONFIG_HEADERS files, > not CONFIG_FILES files, so classifying stamp-h as the latter kind > would make things work. That would probably work, but I'm kind of hesitant to create an empty input file in cvs just to serve this marginal feature. (It wouldn't take /dev/null because it tries to use .//dev/null.) Moreover, the likely candidate name stamp-h.in is sort of reserved for doing the same trickery on autoheader, in case we ever use that. I came up with this: diff -c -r1.86 configure.in *** configure.in 2001/01/01 23:10:09 1.86 --- configure.in 2001/01/02 19:20:16 *************** *** 1140,1144 **** ], [ # Update timestamp for config.h (see Makefile.global) ! echo >src/include/stamp-h ]) --- 1140,1144 ---- ], [ # Update timestamp for config.h (see Makefile.global) ! test x"$CONFIG_HEADERS" != x"" && echo >src/include/stamp-h ]) This only updates the stamp file if config.h is actually being considered by config.status. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> [
> # Update timestamp for config.h (see Makefile.global)
> ! test x"$CONFIG_HEADERS" != x"" && echo >src/include/stamp-h
> ])
> This only updates the stamp file if config.h is actually being considered
> by config.status.
Someday there will need to be a sed or grep test there to see if
config.h is actually mentioned in $CONFIG_HEADERS. But as long as
we only have one output headerfile, it should work ...
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes: > That would probably work, but I'm kind of hesitant to create an empty > input file in cvs just to serve this marginal feature. (It wouldn't take > /dev/null because it tries to use .//dev/null.) Moreover, the likely > candidate name stamp-h.in is sort of reserved for doing the same trickery > on autoheader, in case we ever use that. > > I came up with this: > > diff -c -r1.86 configure.in > *** configure.in 2001/01/01 23:10:09 1.86 > --- configure.in 2001/01/02 19:20:16 > *************** > *** 1140,1144 **** > ], > [ > # Update timestamp for config.h (see Makefile.global) > ! echo >src/include/stamp-h > ]) > --- 1140,1144 ---- > ], > [ > # Update timestamp for config.h (see Makefile.global) > ! test x"$CONFIG_HEADERS" != x"" && echo >src/include/stamp-h > ]) > > This only updates the stamp file if config.h is actually being considered > by config.status. That's the usual approach. For example, when automake is used with a single configuration header in the same directory, it puts this in configure: test -z "$CONFIG_HEADERS" || echo timestamp > stamp-h automake handles these sorts of details automatically. Ian