Skip site navigation (1) Skip section navigation (2)

Re: configure in snapshout == configure.in

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: configure in snapshout == configure.in
Date: 2000-12-27 15:29:31
Message-ID: 7448.977930971@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> There is something busted in the snapshots, that leads to a wrong
> configure file. The file is equal to configure.in (not autoconf'ed).
> First noticed shortly before Christmas.

Last week I tried to do a "make clean" in some subdirectory that's
not cleaned by a toplevel clean -- I think it was doc/src/sgml, but it
might have been a contrib dir -- and make went absolutely nuts.  When
the dust settled I had a toplevel configure file that was identical to
configure.in, just like you describe, and I couldn't do anything because
make kept trying to re-execute configure before it would do anything else.

After I re-fetched a valid copy of configure, I couldn't replicate the
behavior, so I thought maybe I'd mistyped.  But if it's happening in the
snapshot build too, then something is rotten in the makefiles.

I've seen some other bizarre behavior from make lately, like failing to
rebuild utils/SUBSYS.o when some of the utils subdirectories contained
newer SUBSYS.o files.  Again, hard to replicate, but I've seen it.
I'm starting to wonder if our spiffy new makefiles are stressing any
buggy areas of gmake...

FWIW, I'm running GNU Make version 3.79.1, which is the latest release
last I checked.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Adam LangDate: 2000-12-27 16:24:26
Subject: Re: PHP and PostgreSQL
Previous:From: Tom LaneDate: 2000-12-27 15:18:45
Subject: Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group