What has happened to pgxs?

Thomas Hallgren wrote:

Hi,
I tried to compile PL/Java against PostgreSQL 8.1beta2. I use pgxs and
until now that has been just fine. Now pgxs suggests that the include
files reside under /usr/local/pgsql. They don't of course. Not on my
windows box anyway :-)

I think it stems from the src/Makefile.global. On line 59 it reads:

prefix := /usr/local/pgsql

I guess I'm missing something. Can someone explain to me what I need to
change?

Take a look at Makefile.global.in. That value is defined by the
--prefix flag when you run configure. The default is /usr/local/pgsql,
and I am guessing you need to change that default on Win32.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Thomas Hallgren wrote:

Hi,
I tried to compile PL/Java against PostgreSQL 8.1beta2. I use pgxs and
until now that has been just fine. Now pgxs suggests that the include
files reside under /usr/local/pgsql. They don't of course. Not on my
windows box anyway :-)

I think it stems from the src/Makefile.global. On line 59 it reads:

prefix := /usr/local/pgsql

I guess I'm missing something. Can someone explain to me what I need to
change?

Take a look at Makefile.global.in. That value is defined by the
--prefix flag when you run configure. The default is /usr/local/pgsql,
and I am guessing you need to change that default on Win32.

I'm using a pre-compiled installation of PostgreSQL. All I want to do is
use pgxs to be able to compile PL/Java.

There is other stuff that seems strange to me. Why do you append
'postgresql' to the include directories further down in the file? I had
to remove that in order to compile.

Regards,
Thomas Hallgren

Thomas Hallgren wrote:

I'm using a pre-compiled installation of PostgreSQL. All I want to do is
use pgxs to be able to compile PL/Java.

There is other stuff that seems strange to me. Why do you append
'postgresql' to the include directories further down in the file? I had
to remove that in order to compile.

Perhaps this is just a problem with the pre-compiled installation?
Perhaps they are using strange configure options and than relocate the
stuff with the installer? I don't know much about Windows stuff, just a
wild guess. I would file a bug report in the pginstaller project on
pgfoundry. pgxs should work.

Best Regards,
Michael Paesold

Michael Paesold wrote:

Thomas Hallgren wrote:

I'm using a pre-compiled installation of PostgreSQL. All I want to do
is use pgxs to be able to compile PL/Java.

There is other stuff that seems strange to me. Why do you append
'postgresql' to the include directories further down in the file? I
had to remove that in order to compile.

Perhaps this is just a problem with the pre-compiled installation?
Perhaps they are using strange configure options and than relocate the
stuff with the installer? I don't know much about Windows stuff, just
a wild guess. I would file a bug report in the pginstaller project on
pgfoundry. pgxs should work.

I followed your advice. Here's a link:
http://pgfoundry.org/tracker/index.php?func=detail&aid=1000388&group_id=1000007&atid=126

There's another issue with the Makefile.global.in that I feel should be
addressed here. The file contains a lot of entries like:

ifeq "$(findstring pgsql, $(pkgincludedir))" ""
ifeq "$(findstring postgres, $(pkgincludedir))" ""
override pkgincludedir := $(pkgincludedir)/postgresql
endif
endif

Guess what happens if the install-location in itself contains the string
postgres?
A more correct way of doing it is probably to check if the directory in
question *ends with* pgsql or postgres rather then if it contains it.

Regards,
Thomas Hallgren

Sorry, that conclusion was wrong. What happens is:
1. I change the prefix in Makefile.global to say,
C:/Progra~1/PostgreSQL/8.1-beta2 (this is the default for the installer).
2. I compile.

That triggers the append of 'postgresql' on all directories since my
install location *does not* contain the word 'postgres' nor 'pgsql'.

Regards,
Thomas Hallgren

Thomas Hallgren wrote:

Thomas Hallgren wrote:

Sorry, that conclusion was wrong. What happens is:
1. I change the prefix in Makefile.global to say,
C:/Progra~1/PostgreSQL/8.1-beta2 (this is the default for the installer).
2. I compile.

That triggers the append of 'postgresql' on all directories since my
install location *does not* contain the word 'postgres' nor 'pgsql'.

...

Thomas Hallgren wrote:

There's another issue with the Makefile.global.in that I feel should be
addressed here. The file contains a lot of entries like:

ifeq "$(findstring pgsql, $(pkgincludedir))" ""
ifeq "$(findstring postgres, $(pkgincludedir))" ""
override pkgincludedir := $(pkgincludedir)/postgresql
endif
endif

Bruce, others, could this comparision be made case-insensitive at least, so
that it at least finds "PostgreSQL" and does not append postgresql in that
case?

That would be the least invasive fix for the Windows case, I guess, where
the default installation directory contains "PostgreSQL".

Best Regards,
Michael Paesold

Thomas Hallgren <thhal@mailblocks.com> writes:

There's another issue with the Makefile.global.in that I feel should be
addressed here. The file contains a lot of entries like:

ifeq "$(findstring pgsql, $(pkgincludedir))" ""
ifeq "$(findstring postgres, $(pkgincludedir))" ""
override pkgincludedir := $(pkgincludedir)/postgresql
endif
endif

Guess what happens if the install-location in itself contains the string
postgres?

That's the way it's supposed to work. The point of this code is just
to not dump the install files directly into common directories like
/usr/local/include. If "postgres" appears anywhere in the string then
it's obviously not a common directory.

regards, tom lane

"Michael Paesold" <mpaesold@gmx.at> writes:

Bruce, others, could this comparision be made case-insensitive at least, so
that it at least finds "PostgreSQL" and does not append postgresql in that
case?

We could certainly add "PostgreSQL" to the set of checked-for strings,
but...

That would be the least invasive fix for the Windows case, I guess, where
the default installation directory contains "PostgreSQL".

It does? Dave just told us that the standard installer package is built
to install into /usr/local/pgsql. So I'm not seeing where the complaint
is coming from.

regards, tom lane

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: 23 September 2005 15:24
To: Michael Paesold
Cc: Thomas Hallgren; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] What has happened to pgxs?

"Michael Paesold" <mpaesold@gmx.at> writes:

Bruce, others, could this comparision be made

case-insensitive at least, so

that it at least finds "PostgreSQL" and does not append

postgresql in that

case?

We could certainly add "PostgreSQL" to the set of checked-for strings,
but...

That would be the least invasive fix for the Windows case,

I guess, where

the default installation directory contains "PostgreSQL".

It does? Dave just told us that the standard installer
package is built
to install into /usr/local/pgsql. So I'm not seeing where
the complaint
is coming from.

No, I said it's built into the installer from /usr/local/pgsql (the path
in the msys dev environment). It actually installs into C:\Program
Files\PostgreSQL\8.X which is where users run it from.

Regards, Dave

"Dave Page" <dpage@vale-housing.co.uk> writes:

It does? Dave just told us that the standard installer
package is built to install into /usr/local/pgsql.

No, I said it's built into the installer from /usr/local/pgsql (the path
in the msys dev environment). It actually installs into C:\Program
Files\PostgreSQL\8.X which is where users run it from.

Hmm ... so the real issue is that pgxs sees the installation directory
as named differently from what it was named during backend build. OK,
that makes this behavior a problem, considering that we nominally
support being able to relocate installations. Not sure what to do
about it though. Perhaps pgxs should be interrogating pg_config for
the various path names instead of assuming it can recompute them?

regards, tom lane

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 23 September 2005 15:48
To: Dave Page
Cc: Michael Paesold; Thomas Hallgren; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] What has happened to pgxs?

"Dave Page" <dpage@vale-housing.co.uk> writes:

It does? Dave just told us that the standard installer
package is built to install into /usr/local/pgsql.

No, I said it's built into the installer from

/usr/local/pgsql (the path

in the msys dev environment). It actually installs into C:\Program
Files\PostgreSQL\8.X which is where users run it from.

Hmm ... so the real issue is that pgxs sees the installation directory
as named differently from what it was named during backend build. OK,
that makes this behavior a problem, considering that we nominally
support being able to relocate installations. Not sure what to do
about it though. Perhaps pgxs should be interrogating pg_config for
the various path names instead of assuming it can recompute them?

That would be a definite improvement, however it may well run into the
whitespace issues that Thomas mentioned - apparently the makefiles need
short Windows filenames if there are any spaces in them - eg, instead
of:

C:/Program Files/PostgreSQL

We need

C:/Progra~1/PostgreSQL

The GetShortPathName() API should do this, though some reversing of the
/'s might be required first (and if so, they'll need to be flipped back
again afterwards). I'm tied up with other stuff right now though so I
can't really look atm.

Regards, Dave.