[postgis-devel] Death to PGXS

[Mark Cave-Ayland]

On 04/12/14 21:20, Paul Ramsey wrote:

> I’m somewhat at a loss as to what PGXS is buying us anymore. We can get
> all the proper install locations and paths and so on directly from
> pg_config. Using PGXS means we inherit from the PostgreSQL build
> sometimes complete annoying build stuff, like flags we don’t want (or
> lack of flags we *do* want, like say debugging or profiling flags).
> 
> More terribly, I found a postgresql93 package on freebsd that was
> compiled in an environment apparently without perl, so PGXS defines
> $(PERL) as "/bin/sh
> /usr/local/lib/postgresql/pgxs/src/makefiles/../../config/missing”,
> which doesn’t really help our build at all.
> 
> Similarly, and also terribly, I found the postgresql package on Solaris
> from OpenCSW is built with $(CC) defined as "/opt/solarisstudion/bin/cc”
> or somesuch, suffice to say it was a compiler I did not have ready
> access to without going through a big manual register, donate kidney,
> install process.
> 
> Why can’t we drop PGXS and start controlling our own build/install
> destiny again? As long as we listen carefully to what pg_config is
> telling us, it should all work fine, no?

There were several reasons for why using PGXS was the best option at the
time when I did the last revamp of the build system:

1) Lack of path continuity between different PostgreSQL versions

The paths to various parts of the PostgreSQL installation, e.g. sharedir
changed between versions. As the previous PostGIS Makefile was a static
snapshot from an older version, we ended up finding that files would be
installed in the wrong location for which the only solution was to add
per-version hacks into the Makefile.

2) Missing parameters from pg_config

>From memory there were missing parameters from pg_config at the time
when I wrote the PGXS code (possibly related to versioning and docdir?)
and so the only way to get these locations was from PGXS Makefile variables.

3) Missing support for various flavours of BSD

I seem to recall bug reports from some of the BSDs failing to build
PostGIS because the PostgreSQL Makefile had been updated with bugfixes
and we hadn't manually updated the PostGIS Makefile to match (and
keeping our Makefile in sync with upstream plus local hacks was a
horrible time-consuming job).

4) Prevent mixing of incompatible build flags

I've had instances in the past where the hardcoded PostGIS Makefile
flags don't match the flags to build PostgreSQL, e.g. missing/adding
-fPIC/-fpic and with pie enabled/disabled which cause some strange
issues at runtime. And what if PostgreSQL was built with SSP and PostGIS
wasn't - is the resulting binary protected?

5) Aim to integrate with the PostgreSQL regression infrastructure

At one point I had hoped to be able to integrate the PostGIS regression
tests into the PostgreSQL regression test architecture, e.g. so we can
re-use the PostgreSQL routines for creating regression databases,
loading data, and checking the resulting diffs.

Obviously some of these things may no longer be relevant, however it
seemed useful to document the reasoning for the archives.

Now for your particular reports above:

a) FreeBSD

- This seems strange as I thought perl was a mandatory build requirement
for PostgreSQL these days? Why else would it be defined but not used?

b) OpenCSW

- Here the packages have been built with Sun's compiler which has been
known to be buggy, especially if the latest updates haven't been
installed due to an expired subscription. You could install SunStudio
(why isn't this listed as a dependency for a postgresql development
package?) but personally I wouldn't even bother with the packages on old
Solaris and instead build PostgreSQL from source with gcc which will
also give you a proper build environment ready to go.

IMO these are packaging faults rather than problems with the PGXS system
itself.

The key point really is to weigh up the pros and cons of switching away
from PGXS. There has been talk of CMake in the past, but the main issue
last time I looked was that it didn't support nearly as many platforms
as PostgreSQL, and so this could leave users of less common setups
suddenly unable to use PostGIS. But of course this could have changed in
the meantime.

I think one point to bear in mind is that before PGXS, the mailing list
often had threads with build issues which were time-consuming to solve
(a source of inspiration for the issues above!), whilst after PGXS these
reports practically dropped to zero. Now I can't say that I build
PostGIS often enough these days to deserve a veto on a decision to
change, but I hope that at least I can offer explanations as to why PGXS
was chosen and the issues that need to be considered based upon my
(often painful) experience.


ATB,

Mark.