[postgis-devel] Death to PGXS

[Paul Ramsey]

Thanks for the refresher Mark.
  I think inevitably removing PGXS will expose a bunch of other corner cases that are currently papered over, so it’s probably a wash. Given that, since the corner cases that *I* exposed (building from source against packaged pgsql) are rare in their own way (packagers will necessarily be building everything at once, and can solve it at source; users of packaged everything will not see the problem anyways; developers can always just fall back to building everything, including pgsql, which is what I did for solaris and am going to do for freebsd) aren’t all that widespread, I’m not inclined to rip off this bandage just for fun. 
  The CMake thing remains as the eventual prod to make a big build re-org happen, but I’m not sure who’s going to grasp that nettle or when :)
P.

-- 
Paul Ramsey
http://cleverelephant.ca
http://postgis.net

On December 4, 2014 at 6:16:56 PM, Mark Cave-Ayland (mark.cave-ayland at ilande.co.uk) wrote:

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.  

_______________________________________________  
postgis-devel mailing list  
postgis-devel at lists.osgeo.org  
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20141205/003e120e/attachment.html>