Re: make check failure for 8.4.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: make check failure for 8.4.0
Date: 2009-07-20 03:52:53
Message-ID: 18329.1248061973@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Kevin Grittner wrote:
>> Bingo! A few weeks back I had been experimenting with using the PGXS
>> compiles for our extensions, rather than expanding our tarballs in the
>> build tree and just doing make and sudo make install there. On the
>> failing machine, the session I used has USE_PGXS defined. I unset
>> that and out of paranoia I did a make distclean and started over.

> This seems like a bug in the PGXS stuff that oughta be fixed.

Well, PGXS per se is just doing what it was told to. What I was
thinking is that we should arrange to un-define USE_PGXS during a
standard in-tree build of contrib/. It's not quite clear to me
where that should happen though. Is contrib/Makefile the right place?
That would mean that issuing "make" within a contrib module directory
might behave differently from saying "make" at a higher level. Maybe
that's what we want --- I can certainly imagine wishing to activate
PGXS while building a contrib module, even if it happens to be inside
a Postgres source tree.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-07-20 03:58:34 Re: join removal
Previous Message Tom Lane 2009-07-20 03:47:29 Re: Problem with psql backward compatibility