From: =?utf-8?q?C=C3=A9dric_Villemain?= <cedric@2ndquadrant.com>
Reply-To: cedric@2ndquadrant.com
Organization: 2ndQuadrant
To: pgsql-hackers@postgresql.org
Subject: Re: Bugfix and new feature for PGXS
Date: Sat, 29 Jun 2013 20:27:57 +0200
User-Agent: KMail/1.13.7 (Linux/3.8-2-amd64; KDE/4.8.4; x86_64; ; )
Cc: Andrew Dunstan <andrew@dunslane.net>, Craig Ringer <craig@2ndquadrant.com>
References: <201306181552.36673.cedric@2ndquadrant.com>
 <51CB0011.8020506@dunslane.net> <51CF1F6D.8020209@dunslane.net>
In-Reply-To: <51CF1F6D.8020209@dunslane.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4191075.KLTkv8bWF1";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201306292027.58057.cedric@2ndquadrant.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--nextPart4191075.KLTkv8bWF1
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Le samedi 29 juin 2013 19:54:53, Andrew Dunstan a =C3=A9crit :
> 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
> >>>>>> 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.
> >>>>>=20
> >>>>> 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
> >>>>>=20
> >>>>> 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.
> >>>>=20
> >>>> 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=3D/mypath ..." the
> >>>> VPATH
> >>>> provided won't be erased by the pgxs.mk logic.
> >>>=20
> >>> 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 thi=
nk
> >>> 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.
> >>=20
> >> 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.
> >=20
> > 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.
> >=20
> > Here's what I did that works like I think it should.
> >=20
> > First the attached patch on top of yours.
> >=20
> > 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 .
> >=20
> > Then I created vpath.mk with these contents:
> >     ext_srcdir =3D ../json_build
> >     USE_VPATH =3D $(ext_srcdir)
> >=20
> > Finally I vpath-ized the Makefile (see attached).
> >=20
> > Given all of that, I was able to do, in the vpath directory:
> >     make
> >     make install
> >     make installcheck
> >     make clean
> >=20
> > and it all just worked, with exactly the same make invocations as work
> > in an in-tree build.
> >=20
> > So what's lacking to make this nice is a tool to automate the second
> > and third steps above.
> >=20
> > Maybe there are other ways of doing this, but this does what I'd like
> > to see.
>=20
> 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 did so I sent the mail again. I believe your addition need some changes t=
o=20
allow  the PGXS+VPATH case as it currently depends on the source-tree tool.=
 So=20
it needs to be in postgresql-server-devel packages, thus installed by=20
postgresql "make install".
I'm going to update the doc. It's probably worth to have some examples.

> 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.

Yes, it is valuable to help packagers here, thanks.
=2D-=20
C=C3=A9dric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - D=C3=A9veloppement, Expertise et Formation

--nextPart4191075.KLTkv8bWF1
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAABAgAGBQJRzyctAAoJENsgH0yzVBebP3UH/3TPecYwfmnbTN3jiK9MMNoY
HusvcK0CUSXiSHJt1dv4uC2iQryZ3iscxNWvRlZXatpVpj4JhNQ+Vf/+rihTCLka
SUZ7YJWz22pOU8GWThgJmZcpKn5mXmmf3kK51Y1LCr265Xd5coOcwlIWDHUXAEPi
BXqSJKB+YQoqv9srepIhVel1be6n7Cz5fEVN8uD3JkXfWrDlg71zAa/NCvd6oI1N
dMTQo0pQo2ho9O281tjoOKbfthYTrbDbVQK02iha16taEfVhvcFIyN5v53VVapkz
h19PFSiFeGnEqY/yerYhZwgBMwvfeoJ8ZOrvFx/LZkDYYNJnBZyEGhT39GRgYBY=
=Eyc5
-----END PGP SIGNATURE-----

--nextPart4191075.KLTkv8bWF1--