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-26 14:52:01 |
Message-ID: | 51CB0011.8020506@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
pgxs-usevpath.patch | text/x-patch | 1.0 KB |
Makefile | text/plain | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-06-26 14:54:16 | Re: LATERAL quals revisited |
Previous Message | Markus Wanner | 2013-06-26 14:47:09 | Re: Hash partitioning. |