> > The above is all about getting the build system to work at all. If that > isn't a showstopper there's a subsequent discussion to be had about older > platforms where one could get the build system to work but convenient > packages are missing. For example not even RHEL7 has any Python3 packages > in the base system (it does in Software Collections though) which means > some extra hoops on getting meson running there. And RHEL5 is in an even > worse spot as it has no Software Collections, who knows if Python 3 builds > on it out of the box etc. >
I would expect that a new version of software should not target versions of platform that are end of full support. Per https://access.redhat.com/support/policy/updates/errata currently only RHEL7 is at Full Support, and RHEL5 is already past Product Retirement. I would say it's fine to support these at already released branches, but limiting . PostGIS has several forks that move it towards CMake (five-year-old ticket https://trac.osgeo.org/postgis/ticket/2362, forks https://github.com/nextgis-borsch/postgis, https://github.com/mloskot/postgis/tree/cmake-build) - none of these are upstream mostly because there's an expectation to match the Postgres build system. If Postgres moved to CMake (there are already CMake-enabled forks available for people who) then I expect PostGIS to quickly catch up. A lot of libraries PostGIS depends on are already built using CMake, so if the platform has recent PostGIS it has CMake available somehow. Darafei Praliaskouski, GIS Engineer / Juno Minsk
