[postgis-devel] PostGIS 3 and MobilityDB

[Regina Obe]

Esteban,

 

I just tested against your develop branch and it still fails at detecting my PostgreSQL version  – my comments here - https://github.com/MobilityDB/MobilityDB/pull/20#issuecomment-877973757

 

I think using sed and awk in a cmake project is a big NO NO.  First of all sed behaves differently across platforms and is not even available on some.  For example windows does not have sed or awk natively.

 

That said – you are using CMAKE use CMAKE the way it was intended.  As I mentioned in that pull request, you should follow how pgRouting detects

 

https://github.com/pgRouting/pgrouting/blob/main/CMakeLists.txt#L165

 

pgRouting is distributed by many distros and cloud providers and the detection logic Vicky has put in place works across all of them.

 

Hope that helps,

Regina

 

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Esteban Zimanyi
Sent: Saturday, July 10, 2021 8:34 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Cc: Mahmoud Sakr <m_attia_sakr at yahoo.com>; mohamed sayed <mohamed_bakli at aun.edu.eg>; SCHOEMANS Maxime <Maxime.Schoemans at ulb.be>
Subject: Re: [postgis-devel] PostGIS 3 and MobilityDB

 

Dear Regina

 

Regarding the way we detect PostgreSQL, according to my understanding we are doing similar things as done in PostGIS. In the configure file of PostGIS 3.1.2 it is stated

 

  PGSQL_FULL_VERSION=`"$PG_CONFIG" --version`
  PGSQL_MAJOR_VERSION=`echo $PGSQL_FULL_VERSION | sed 's/[^0-9]*\([0-9]*\).*/\1/'`
  PGSQL_MINOR_VERSION=`$PG_CONFIG --version | sed 's/[^0-9]*\([0-9]\)\.\([0-9]\).*/\2/'`

 

In our CMakeLists.txt we do

 

  execute_process(COMMAND ${PGCONFIG} --version OUTPUT_VARIABLE PG_VERSION_STRING OUTPUT_STRIP_TRAILING_WHITESPACE)

and continue stripping the major and minor versions in a less efficient way than you do. There is no problem in reusing your recipe for doing that.

 

Regarding the PostGIS issue, as I commented in your PR over github

---- (copied from github) ---

Actually, we use postgis-2.5.so <http://postgis-2.5.so/>  just to ensure the version, we don't do anything with it. I commented the following lines in the CMakeLists.txt and everything works, the tests pass without any problem.

find_library(HAS_LWGEOM lwgeom)
if (HAS_LWGEOM)
MESSAGE(STATUS "Found LWGEOM at ${HAS_LWGEOM} - compiling with PostGIS support")
--> if(NOT EXISTS "${PostgreSQL_EXTLIB_DIR}/postgis-2.5.so <http://postgis-2.5.so/> ")
--> message(FATAL_ERROR "Could not find postgis-2.5.so <http://postgis-2.5.so/> ; only PostGIS 2.5 is currently supported")
--> endif()
else()
message(FATAL_ERROR "Could not find lwgeom; ")
endif ()

---- (copied from github) ---

we did that to avoid the use of PostGIS 3 with MobilityDB until we solve this issue (as we are discussing in the current thread). As soon as you tell us how to solve this we will change this immediately.

 

Many many thanks for your continuous support !

 

Esteban

 

On Fri, Jul 9, 2021 at 8:27 AM Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

A side note, I think you need to change the way you are detecting PostgreSQL.  It just doesn’t work for me and suspect it will be an issue for anyone with multiple PostgreSQL installs or non-standard paths  – as I had mentioned here - https://github.com/MobilityDB/MobilityDB/pull/20 .  You should be using the 

CMAKE PostgreSQL package to detect PostgreSQL.  I always end up having to copy pgRouting code in so the PostgreSQL detection works right.

 

As I recall compiling MobilityDB a while ago it has both a dependency to liblwgeom as well as the PostGIS lib.

The dependency of PostGIS lib is a little troubling as I mentioned here

 

https://github.com/MobilityDB/MobilityDB/issues/16

 

Even the extensions packaged with PostGIS don’t have a direct dependency to PostGIS lib just to liblwgeom.

 

So not even a parallel branch will work here unless you change how you are doing things and what to change is unclear to me.  The issue with depending on PostGIS lib is we only guarantee SQL API compatibility across minor versions, not C-API.  Meaning if the function isn’t exposed via the SQL API, we don’t need to worry about it as PostgreSQL upgrade would not care as it only fails if it tries to call a function that is referenced in an SQL API function.

 

That said if you must rely on PostGIS lib all your postgis.h dependencies should only be Datum ones and any others will make your code brittle to PostGIS changes.

I’m thinking for the liblwgeom dependency you should be able to use librtopo for that. Still not clear to me why you can’t, but we can discuss in dev meeting. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210712/3184c0d1/attachment.html>