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: 5503.1127779957@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I looked at the recently noted problem that pgxs builds only work
if the installation paths recorded in Makefile.global are accurate;
which pretty much breaks our claim to supporting relocatable
installations.

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

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

Since a pgxs build has already assumed it could use pg_config to find
pgxs.mk, 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 Makefile.global are currently
available from pg_config; the missing ones are

prefix
exec_prefix
sbindir
mandir
localedir
libexecdir
datadir
sysconfdir
pkgincludedir
docdir

The first three of these don't seem to be directly referenced anywhere
in the Makefiles, so I propose just removing them from Makefile.global.
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

Comments?

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

Responses

Browse pgsql-hackers by date

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