pgsql/src (Makefile.global.in)

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