|From:||Andrew Dunstan <andrew(at)dunslane(dot)net>|
|Cc:||pgsql-hackers(at)postgresql(dot)org, Craig Ringer <craig(at)2ndquadrant(dot)com>|
|Subject:||Re: Bugfix and new feature for PGXS|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 06/18/2013 09:52 AM, Cédric Villemain wrote:
> I've rebased the current set of pending patches I had, to fix pgxs and added 2
> new patches.
> Bugfixes have already been presented and sent in another thread, except the
> last one which only fix comment in pgxs.mk.
> The new feature consists in a new variable to allow the installation of
> contrib header files.
> A new variable MODULEHEADER can be used in extension Makefile to list the
> header files to install.
> The installation path default to $includedir/$includedir_contrib/$extension.
> 2 new variables are set to define directories: $includedir_contrib and
> $includedir_extension, the former default to include/contrib and the later to
> $includedir_contrib/$extension ($extension is the name of the extension).
> This allows for example to install hstore header and be able to include them
> in another extension like that:
> # include "contrib/hstore/hstore.h"
> For packagers of PostgreSQL, this allows to have a postgresql-X.Y-contrib-dev
> For developers of extension it's killing the copy-and-paste-this-function
> dance previously required.
> I've not updated contribs' Makfefile: I'm not sure what we want to expose.
> I've 2 other patches to write to automatize a bit more the detection of things
> to do when building with USE_PGXS, based on the layout. Better get a good
> consensus on this before writing them.
> New feature:
> I'll do a documentation patch based on what is accepted in HEAD and/or
> previous branches.
I have just spent an hour or two wrestling with the first four of these.
Items 5 and six are really separate items, which I'm not considering at
The trouble I have is that there are no instructions on how to modify
your Makefile or prepare a vpath tree, so I have been flying blind. I
started out doing what Postgres does, namely to prepare the tree using
config/prep_buildtree. This doesn't work at all - the paths don't get
set properly unless you invoke make with the path to the real makefile,
and I'm not sure they all get set correctly then. But that's not what we
expect of a vpath setup, or at least not what I expect. I expect that
with an appropriately set up make file and a correctly set up build tree
I can use an identical make invocation to the one I would use for an
in-tree build. That is, after setting up I should be able to ignore the
fact that it's a vpath build.
FYI I deliberately chose a non-core extension with an uncommon layout
for testing: json_build <https://github.com/pgexperts/json_build>
So, patches 1, 2 and 6 look sane enough, and I'm inclined to commit them
just to get them out of the way. That means two of the commitfest items
I am signed up for will be committed and two marked "Returned with
comments". I think we need some more discussion about how VPATH builds
should work with extensions, and subject to what limitations if any.
|Next Message||Josh Berkus||2013-06-24 17:40:48||Re: [9.4 CF 1] The Commitfest Slacker List|
|Previous Message||Joshua D. Drake||2013-06-24 17:37:02||Re: [9.4 CF 1] The Commitfest Slacker List|