Re: Bugfix and new feature for PGXS - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: Bugfix and new feature for PGXS |
Date | |
Msg-id | 51CB0011.8020506@dunslane.net Whole thread Raw |
In response to | Re: Bugfix and new feature for PGXS (Cédric Villemain <cedric@2ndquadrant.com>) |
Responses |
Re: Bugfix and new feature for PGXS
Re: Bugfix and new feature for PGXS |
List | 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
pgsql-hackers by date: