Re: configure in snapshout == configure.in

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: configure in snapshout == configure.in
Date: 2000-12-28 17:57:26
Message-ID: Pine.LNX.4.30.0012281842510.1096-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> >> FWIW, I'm running GNU Make version 3.79.1, which is the latest release
> >> last I checked.
>
> > ... but not necessarily the best. :-(
>
> What do you recommend? IIRC, I updated to this version because it fixed
> a bug that was biting me in gmake 3.78.1.

3.76.1 works best for me. 3.79.1 is okay, especially since it has a
number of nice new features. Everything in between is sheer folly.

The most annoying thing is that rule chains of the form

all: foo.so

%.so: %.o
$(LD) ...

# implicit %.o: %.c here

broke after 3.76.1 and have not been repaired. (I'm not sure exactly what
the cause is as I have not been able to reproduce this with a dummy
makefile, but it probably has something to do with the fact that two
implicit rules are chained, with some other things interacting.)

When you first run 'make all' it will build foo.o and foo.so, then delete
foo.o because it's intermediate. That's okay. Then you run 'make all'
again (or perhaps via 'make install'), it will notice the missing foo.o
file and rebuild it and foo.so. That's stupid.

Now I figured that I could avoid the deleting of the intermediate file
altogether by mentioning the target .SECONDARY:, but that will break in
3.78 if the %.c file is itself build from somewhere. In that case it will
just bark with "not rule to make foo.c" or so.

You can see me cursing about this in the cvs logs, and this experience
made me install all the gmake versions I could find and try then regularly
when attempting something cute. (So all recent gmake versions *should*
work with PostgreSQL, but I won't guarantee the corner cases.)

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-12-28 20:54:50 Assuming that TAS() will succeed the first time is verboten
Previous Message Tom Lane 2000-12-28 17:41:44 Re: Alpha tas() patch