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 pos
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 late
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 di
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 thin
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. Commen
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: /cvsroot/pg
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 definitio
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
> exte
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:
> 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 thin
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, t
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 r
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
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 th
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
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 insta
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 reasoni
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 prefix
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 prefix=~/install_dir
3. gmake prefix=~/install_dir
4. gmake install prefix=~/install_di
19 matches
Mail list logo
