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-29 17:54:53 |
Message-ID: | 51CF1F6D.8020209@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/26/2013 10:52 AM, Andrew Dunstan wrote:
>
> 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.
I haven't seen a response to this. One thing we are missing is
documentation. Given that I'm inclined to commit all of this (i.e.
cedric's patches 1,2,3, and 4 plus my addition).
I'm also inclined to backpatch it, since without that it seems to me
unlikely packagers will be able to make practical use of it for several
years, and the risk is very low.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2013-06-29 18:18:58 | Re: Bugfix and new feature for PGXS |
Previous Message | Jeff Davis | 2013-06-29 17:30:43 | Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls |