Re: Bugfix and new feature for PGXS

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: cedric(at)2ndquadrant(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org, Craig Ringer <craig(at)2ndquadrant(dot)com>
Subject: Re: Bugfix and new feature for PGXS
Date: 2013-06-25 15:18:51
Message-ID: 51C9B4DB.8000007@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2013-06-25 15:29:42 Re: Bugfix and new feature for PGXS
Previous Message Robert Haas 2013-06-25 15:15:24 Re: Hash partitioning.