Re: Bugfix and new feature for PGXS - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Bugfix and new feature for PGXS
Date
Msg-id 51C9B4DB.8000007@dunslane.net
Whole thread Raw
In response to Re: Bugfix and new feature for PGXS  (Cédric Villemain <cedric@2ndquadrant.com>)
Responses Re: Bugfix and new feature for PGXS
List pgsql-hackers
On 06/24/2013 07:24 PM, Cédric Villemain wrote:
> Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit :
>> On 06/24/2013 04:02 PM, Cédric Villemain wrote:
>>> WIth extension, we do have to set VPATH explicitely if we want to use
>>> VPATH (note that contribs/extensions must not care that postgresql has
>>> been built with or without VPATH set). My patches try to fix that.
>> No, this is exactly what I'm objecting to. I want to be able to do:
>>
>>      invoke_vpath_magic
>>      standard_make_commands_as_for_non_vpath
>>
>> Your patches have been designed to overcome your particular issues, but
>> they don't meet the general case, IMNSHO. This is why I want to have
>> more discussion about how vpath builds could work for PGXS modules.
> The patch does not restrict anything, it is not supposed to lead to
> regression.
> The assignment of VPATH and srcdir are wrong in the PGXS case, the patch
> correct them. You're still free to do "make VPATH=/mypath ..." the VPATH
> provided won't be erased by the pgxs.mk logic.



I still think this is premature.  I have spent some more time trying to
make it work the way I think it should, so far without success. I think
we need more discussion about how we'd like VPATH to work for PGXS
would. There's no urgency about this - we've lived with the current
situation for quite a while.

When I have more time I will work on it some more.

cheers

andrew




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Hash partitioning.
Next
From: Robert Haas
Date:
Subject: Re: Hash partitioning.