Message-ID: <51CF1F6D.8020209@dunslane.net>
Date: Sat, 29 Jun 2013 13:54:53 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: cedric@2ndquadrant.com
CC: pgsql-hackers@postgresql.org, Craig Ringer <craig@2ndquadrant.com>
Subject: Re: Bugfix and new feature for PGXS
References: <201306181552.36673.cedric@2ndquadrant.com>
 <201306250124.54610.cedric@2ndquadrant.com> <51C9B4DB.8000007@dunslane.net>
 <201306251729.47025.cedric@2ndquadrant.com> <51CB0011.8020506@dunslane.net>
In-Reply-To: <51CB0011.8020506@dunslane.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 06/26/2013 10:52 AM, Andrew Dunstan wrote:
>
> On 06/25/2013 11:29 AM, C=C3=A9dric Villemain wrote:
>> Le mardi 25 juin 2013 17:18:51, Andrew Dunstan a =C3=A9crit :
>>> On 06/24/2013 07:24 PM, C=C3=A9dric Villemain wrote:
>>>> Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a =C3=A9crit :
>>>>> On 06/24/2013 04:02 PM, C=C3=A9dric Villemain wrote:
>>>>>> WIth extension, we do have to set VPATH explicitely if we want to=20
>>>>>> use
>>>>>> VPATH (note that contribs/extensions must not care that=20
>>>>>> 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=20
>>>>> 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=20
>>>> patch
>>>> correct them. You're still free to do "make VPATH=3D/mypath ..." the=20
>>>> 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=20
>> install)
>> As you're constructing targets based on commands to execute in the=20
>> srcdir
>> directory, and because srcdir is only set in pgxs.mk, it is possible=20
>> 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=20
> invoke make without anything special in the invocation that triggers=20
> 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 =3D ../json_build
>     USE_VPATH =3D $(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=20
> in an in-tree build.
>
> So what's lacking to make this nice is a tool to automate the second=20
> and third steps above.
>
> Maybe there are other ways of doing this, but this does what I'd like=20
> to see.


I haven't seen a response to this. One thing we are missing is=20
documentation. Given that I'm inclined to commit all of this (i.e.=20
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=20
unlikely packagers will be able to make practical use of it for several=20
years, and the risk is very low.

cheers

andrew


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers