Thread: pgsql/src (Makefile.global.in)

pgsql/src (Makefile.global.in)

From
tgl@postgresql.org
Date:
  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.


Re: pgsql/src (Makefile.global.in)

From
Peter Eisentraut
Date:
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/


Re: pgsql/src (Makefile.global.in)

From
Tom Lane
Date:
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

Re: pgsql/src (Makefile.global.in)

From
Peter Eisentraut
Date:
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/


Re: pgsql/src (Makefile.global.in)

From
Tom Lane
Date:
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

Re: pgsql/src (Makefile.global.in)

From
Peter Eisentraut
Date:
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/


Re: pgsql/src (Makefile.global.in)

From
Tom Lane
Date:
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

Re: pgsql/src (Makefile.global.in)

From
Peter Eisentraut
Date:
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/


Re: pgsql/src (Makefile.global.in)

From
Tom Lane
Date:
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

Re: [HACKERS] Re: pgsql/src (Makefile.global.in)

From
Ian Lance Taylor
Date:
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