<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Thanks for the refresher Mark.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">  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. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">  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 :)</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">P.</div> <div id="bloop_sign_1417800079808680960" class="bloop_sign">

        <title></title>

        <div>

            <br>

        </div>

        -- <br>

        Paul Ramsey<br>

        http://cleverelephant.ca<div>http://postgis.net

</div>

<script type="application/ld+json">

{

  "@context": "http://schema.org",

  "@type": "em",

  "name": "John Doe",

  "jobTitle": "Graduate research assistant",

  "affiliation": "University of Dreams",

  "additionalName": "Johnny",

  "url": "http://www.example.com",

  "address": {

    "@type": "PostalAddress",

    "streetAddress": "1234 Peach Drive",

    "addressLocality": "Wonderland",

    "addressRegion": "Georgia"

  }

}

</script>

</div> <br><p style="color:#000;">On December 4, 2014 at 6:16:56 PM, Mark Cave-Ayland (<a href="mailto:mark.cave-ayland@ilande.co.uk">mark.cave-ayland@ilande.co.uk</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On 04/12/14 21:20, Paul Ramsey wrote:

<br>

<br>> I’m somewhat at a loss as to what PGXS is buying us anymore. We can get

<br>> all the proper install locations and paths and so on directly from

<br>> pg_config. Using PGXS means we inherit from the PostgreSQL build

<br>> sometimes complete annoying build stuff, like flags we don’t want (or

> lack of flags we *do* want, like say debugging or profiling flags).

<br>>  

<br>> More terribly, I found a postgresql93 package on freebsd that was

<br>> compiled in an environment apparently without perl, so PGXS defines

<br>> $(PERL) as "/bin/sh

<br>> /usr/local/lib/postgresql/pgxs/src/makefiles/../../config/missing”,

> which doesn’t really help our build at all.

<br>>  

<br>> Similarly, and also terribly, I found the postgresql package on Solaris

<br>> from OpenCSW is built with $(CC) defined as "/opt/solarisstudion/bin/cc”

<br>> or somesuch, suffice to say it was a compiler I did not have ready

<br>> access to without going through a big manual register, donate kidney,

<br>> install process.

<br>>  

<br>> Why can’t we drop PGXS and start controlling our own build/install

<br>> destiny again? As long as we listen carefully to what pg_config is

> telling us, it should all work fine, no?

<br>

<br>There were several reasons for why using PGXS was the best option at the

<br>time when I did the last revamp of the build system:

<br>

<br>1) Lack of path continuity between different PostgreSQL versions

<br>

<br>The paths to various parts of the PostgreSQL installation, e.g. sharedir

<br>changed between versions. As the previous PostGIS Makefile was a static

<br>snapshot from an older version, we ended up finding that files would be

<br>installed in the wrong location for which the only solution was to add

per-version hacks into the Makefile.

<br>

<br>2) Missing parameters from pg_config

<br>

<br>From memory there were missing parameters from pg_config at the time

<br>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.

<br>

<br>3) Missing support for various flavours of BSD

<br>

<br>I seem to recall bug reports from some of the BSDs failing to build

<br>PostGIS because the PostgreSQL Makefile had been updated with bugfixes

<br>and we hadn't manually updated the PostGIS Makefile to match (and

<br>keeping our Makefile in sync with upstream plus local hacks was a

horrible time-consuming job).

<br>

<br>4) Prevent mixing of incompatible build flags

<br>

<br>I've had instances in the past where the hardcoded PostGIS Makefile

<br>flags don't match the flags to build PostgreSQL, e.g. missing/adding

<br>-fPIC/-fpic and with pie enabled/disabled which cause some strange

<br>issues at runtime. And what if PostgreSQL was built with SSP and PostGIS

wasn't - is the resulting binary protected?

<br>

<br>5) Aim to integrate with the PostgreSQL regression infrastructure

<br>

<br>At one point I had hoped to be able to integrate the PostGIS regression

<br>tests into the PostgreSQL regression test architecture, e.g. so we can

<br>re-use the PostgreSQL routines for creating regression databases,

loading data, and checking the resulting diffs.

<br>

<br>Obviously some of these things may no longer be relevant, however it

seemed useful to document the reasoning for the archives.

<br>

<br>Now for your particular reports above:

<br>

<br>a) FreeBSD

<br>

<br>- 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?

<br>

<br>b) OpenCSW

<br>

<br>- Here the packages have been built with Sun's compiler which has been

<br>known to be buggy, especially if the latest updates haven't been

<br>installed due to an expired subscription. You could install SunStudio

<br>(why isn't this listed as a dependency for a postgresql development

<br>package?) but personally I wouldn't even bother with the packages on old

<br>Solaris and instead build PostgreSQL from source with gcc which will

also give you a proper build environment ready to go.

<br>

<br>IMO these are packaging faults rather than problems with the PGXS system

itself.

<br>

<br>The key point really is to weigh up the pros and cons of switching away

<br>from PGXS. There has been talk of CMake in the past, but the main issue

<br>last time I looked was that it didn't support nearly as many platforms

<br>as PostgreSQL, and so this could leave users of less common setups

<br>suddenly unable to use PostGIS. But of course this could have changed in

the meantime.

<br>

<br>I think one point to bear in mind is that before PGXS, the mailing list

<br>often had threads with build issues which were time-consuming to solve

<br>(a source of inspiration for the issues above!), whilst after PGXS these

<br>reports practically dropped to zero. Now I can't say that I build

<br>PostGIS often enough these days to deserve a veto on a decision to

<br>change, but I hope that at least I can offer explanations as to why PGXS

<br>was chosen and the issues that need to be considered based upon my

(often painful) experience.

<br>

<br>

<br>ATB,

<br>

Mark.

<br>

<br>_______________________________________________

<br>postgis-devel mailing list

<br>postgis-devel@lists.osgeo.org

<br>http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel

<br></div></div></span></blockquote></body></html>