[Pkg-postgresql-public] pg_bulkload package sponsorship

Alexander acca at cpan.org
Wed May 30 21:47:51 UTC 2012


Hi Dimitri,

On Wed, May 30, 2012 at 9:35 AM, Dimitri Fontaine <dim at tapoueh.org> wrote:
> Alexander <acca at cpan.org> writes:
>> I have temporarily put it at http://acca.it.cx/~assa/pgbulkload/, it
>> is configured for PostgreSQL 8.4
>>
>> 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"?

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.

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.

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.

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.


Any tips would be greatly appreciated.

-- 
Sincerely yours, Alexander Kuznetsov



More information about the Pkg-postgresql-public mailing list