Skip site navigation (1) Skip section navigation (2)

Making pgxs builds work with a relocated installation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Making pgxs builds work with a relocated installation
Date: 2005-09-27 00:12:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I looked at the recently noted problem that pgxs builds only work
if the installation paths recorded in are accurate;
which pretty much breaks our claim to supporting relocatable

What I propose we do about this is change the path setup section
of to look like (for each path variable)

ifdef PGXS
pkglibdir = $(shell pg_config --pkglibdir)
# existing code to set up pkglibdir

Since a pgxs build has already assumed it could use pg_config to find, this isn't introducing any new dependency, and it will allow
the existing relocatable-path code to do its thing.

Not all of the path variables set up in are currently
available from pg_config; the missing ones are


The first three of these don't seem to be directly referenced anywhere
in the Makefiles, so I propose just removing them from
The other ones will need to be added to pg_config's repertoire, unless
someone can make a pretty good case that no pgxs-using module would ever
need to install into that directory.

Also note that I'm assuming the following path variables can continue to
be defined as they are, ie, relative to other path variables that will
get the pg_config treatment:

includedir_server = $(pkgincludedir)/server
includedir_internal = $(pkgincludedir)/internal
pgxsdir = $(pkglibdir)/pgxs


The other open issue in this area was that on Windows, pg_config needs
to return space-free path names to avoid breaking the makefiles.  It was
suggested that this could be handled by passing pg_config's result path
names through GetShortPathName() on that platform.  That sounds OK to me
but I'm not in a position to write or test such a patch; can someone
take care of that?

			regards, tom lane


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-09-27 00:33:22
Subject: Re: State of support for back PG branches
Previous:From: Greg Sabino MullaneDate: 2005-09-27 00:12:15
Subject: Re: Questions about proper newline handling in psql output

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group