It might be worth backpatching the Makefile.global.in patch (ie, the
ifndef addition) to the 8.2 branch, which would allow us to say 8.2.5
or later instead of 8.3 or later, and would bring correspondingly
nearer the time when people can actually use the feature without
thinking much. Comments?
Am Dienstag, 26. Juni 2007 16:12 schrieb Tom Lane:
True. OK, then let's add the ifndef to Makefile.global and change the
existing extension makefiles to
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
Any objections?
Yes. I think that
Dear Peter,
What was the problem with just making all uses of pg_config in
Makefile.global use a hardcoded bindir directly?
Because bindir is given by pg_config:-)
ISTM that the underlying issue, which was not foreseen in the initial pgxs
and fixed later, is that some distributions use a
Fabien COELHO [EMAIL PROTECTED] writes:
What was the problem with just making all uses of pg_config in
Makefile.global use a hardcoded bindir directly?
Because bindir is given by pg_config:-)
ISTM that the underlying issue, which was not foreseen in the initial pgxs
and fixed later, is
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 26. Juni 2007 16:12 schrieb Tom Lane:
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
Any objections?
Yes. I think that solution is wrong. It merely creates other possibilities
With the assumption that the above that one refered to the PG_CONFIG
macro definition in Makefile.global. As existing extension makefiles do
not defined PG_CONFIG, relying on one would break them wrt future
releases?
Ah, I see. I was thinking in terms of breaking them intentionally ;-)
Fabien COELHO [EMAIL PROTECTED] writes:
But ISTM that the remedy (breaking all past makefiles for all extensions)
is not worth the issue.
A better documentation, and possibly following your suggestion with an
explicit PG_CONFIG in contrib makefiles, but without breaking existing
extensions
Let's add the ifndef to Makefile.global and change the
existing extension makefiles to
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
Any objections?
Maybe the := for pg_config is not necessary, = is fine for a
simple string definition ?
Fabien COELHO [EMAIL PROTECTED] writes:
Some documentation (not just code) update seems important to me.
Agreed. I added this to xfunc.sgml's discussion of PGXS makefiles:
Index: doc/src/sgml/xfunc.sgml
===
RCS file:
On Mon, Jun 25, 2007 at 11:42:28PM +1200, Eddie Stanley wrote:
Hi,
I spent the best part of the day trying to work this out - I was working on a
system setup with PG 8.2, and wanted to work with 8.3 for development.
I installed as follows:
1. CVS checkout
2. ./configure
Magnus Hagander [EMAIL PROTECTED] writes:
I was actually about to post on this just a couple of days ago - it seems
pgxs really needs pg_config to be in your PATH.
Correct --- how else is it going to find out where the installation is?
Eddie's proposed solution is of course circular
On Mon, Jun 25, 2007 at 10:43:37AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I was actually about to post on this just a couple of days ago - it seems
pgxs really needs pg_config to be in your PATH.
Correct --- how else is it going to find out where the installation
Magnus Hagander [EMAIL PROTECTED] writes:
On Mon, Jun 25, 2007 at 10:43:37AM -0400, Tom Lane wrote:
Correct --- how else is it going to find out where the installation is?
You can specify the full path in the command to pg_config in your Makefile.
It'd be neat if the makefile could fint that
Fabien COELHO [EMAIL PROTECTED] writes:
ifdef USE_PGXS
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
but something like
ifdef USE_PGXS
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
That would break existing Makefiles that use the please take the
ifdef USE_PGXS
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
but something like
ifdef USE_PGXS
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
to sync these invocations of pg_config with the ones in
Makefile.global. I'm not sure though how to get this setting
Dear Eddie,
MODULES = example
PGXS := $(shell ~/install_dir/bin/pg_config --pgxs)
This is indeed not the intented use of pgxs: it breaks a desirable
property of the makefile that is should be generic wrt postgresql, that
is not particular to an installation.
You are really expected to
Dear Tom,
That would break existing Makefiles that use the please take the first
pg_config in the path feature, which rather make sense (it just means
that you want the extension for your current postgresql).
How would it break them? The default definition is still PG_CONFIG =
pg_config,
Fabien COELHO [EMAIL PROTECTED] writes:
With the assumption that the above that one refered to the PG_CONFIG
macro definition in Makefile.global. As existing extension makefiles do
not defined PG_CONFIG, relying on one would break them wrt future
releases?
Ah, I see. I was thinking in
18 matches
Mail list logo
