Re: Bugfix and new feature for PGXS

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Bugfix and new feature for PGXS
Дата
Msg-id 51CB0011.8020506@dunslane.net
обсуждение исходный текст
Ответ на Re: Bugfix and new feature for PGXS  (Cédric Villemain <cedric@2ndquadrant.com>)
Ответы Re: Bugfix and new feature for PGXS  (Cédric Villemain <cedric@2ndquadrant.com>)
Re: Bugfix and new feature for PGXS  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On 06/25/2013 11:29 AM, Cédric Villemain wrote:
> Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a écrit :
>> 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.
> Sure...
> I did a quick and dirty patch (I just validate without lot of testing),
> attached to this email to fix json_build (at least for make, make install)
> As you're constructing targets based on commands to execute in the srcdir
> directory, and because srcdir is only set in pgxs.mk, it is possible to define
> srcdir early in the json_build/Makefile and use it.


This still doesn't do what I really want, which is to be able to invoke
make without anything special in the invocation that triggers VPATH
processing.

Here's what I did that works like I think it should.

First the attached patch on top of yours.

Second, I did:

     mkdir vpath.json_build
     cd vpath.json_build
     sh/path/to/pgsource/config/prep_buildtree ../json_build .
     ln -s ../json_build/json_build.control .

Then I created vpath.mk with these contents:

     ext_srcdir = ../json_build
     USE_VPATH = $(ext_srcdir)

Finally I vpath-ized the Makefile (see attached).

Given all of that, I was able to do, in the vpath directory:

     make
     make install
     make installcheck
     make clean

and it all just worked, with exactly the same make invocations as work
in an in-tree build.

So what's lacking to make this nice is a tool to automate the second and
third steps above.

Maybe there are other ways of doing this, but this does what I'd like to
see.

cheers

andrew


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: Hash partitioning.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LATERAL quals revisited