[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