Re: Bugfix and new feature for PGXS
От | Andrew Dunstan |
---|---|
Тема | Re: Bugfix and new feature for PGXS |
Дата | |
Msg-id | 51C9B4DB.8000007@dunslane.net обсуждение исходный текст |
Ответ на | Re: Bugfix and new feature for PGXS (Cédric Villemain <cedric@2ndquadrant.com>) |
Ответы |
Re: Bugfix and new feature for PGXS
|
Список | 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 по дате отправления: