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

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 (view raw or flat)
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

pgsql-hackers by date

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

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