[Pkg-postgresql-public] pg_bulkload package sponsorship

Christoph Berg cb at df7cb.de
Wed May 30 22:55:19 UTC 2012


Hi Alexander,

Re: Alexander 2012-05-30 <CA+3pxd4y0ODtMzwSdVALfSH=Yjt3DqCtJoAQeccAXBAU-K94MQ at mail.gmail.com>
> >> TBD (work in progress):
> >>    - switch to pg_buildext to produce entire set of packages for 8.4,
> >> 9.0, 9.1, etc.
> > +1
> 
> There is a minor issue - pg_buildext sets VPATH as $srcdir, thus
> freshly built files are not searched as source, say, for linkage.
> Should it be "$vtarget:$srcdir"?

VPATH is only used for files not found in the current directory, so
freshly built files should still be found even if VPATH points
elsewhere. (I've never seen VPATH=foo:bar before.)

> A bigger issue is that gmake's VPATH is mostly useless with
> subdirectories and hierarchy of Makefiles. Makefiles with relative
> paths inside make the situation even worse.

Yes. You will need to work around that, afaict that's a common
Makefile problem.

> Also I see that /usr/lib/postgresql/XXX/lib/pgxs/src/makefiles/pgxs.mk
> sets VPATH to empty. A stanza in upstream Makefiles:
> 
> PG_CONFIG ?= pg_config
> PGXS := $(shell $(PG_CONFIG) --pgxs)
> include $(PGXS)
> 
> leaves me with no VPATH.

That's not true because variables passed to make on the commandline
override simple "VPATH =" assignments inside Makefiles.

> A solution which could work may be to make configure() in pg_buildext
> to create a copy of $srcdir in $vtarget, but there is also a  package
> dependency problem.

Don't do that, that's exactly what VPATH is meant to avoid.

Having said that, there's plenty of weird make features that are hard
to get around, we should probably add a mode of operation to
pg_buildext that does not do out-of-tree builds.

> libpq and libpq-dev are packages of a certain version with no version
> segregation. While I may have postgresql-server-dev-8.4 and
> postgresql-server-dev-9.1 together, the latter brings libpq-dev (>=
> 9.1~) with its /usr/include/postgresql/pg_config.h. As a result a
> version-aware source gets controversial data from pg_config.h and
> pg_config and finally breaks somewhere.

I haven't yet seen a package where this is a problem. libpq (and hence
its include files) should be compatible enough across different server
version. (If not, that means that file should probably be moved to
/usr/include/postgresql/*.*/server.)

Christoph
-- 
cb at df7cb.de | http://www.df7cb.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/attachments/20120531/92a2561b/attachment.pgp>


More information about the Pkg-postgresql-public mailing list