[postgis-devel] PostGIS 3 and MobilityDB

Regina Obe lr at pcorp.us
Mon Jul 19 14:05:52 PDT 2021


Spoke with Vicky if she can help with your CMake scripts so that I can build under windows at least with the 2.5 without any crazy hacks.  That way I can at least have an idea of what is possible.

 

She’s started looking at the CMake and will work on improving it.

 

Thanks,

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/20210719/c045010e/attachment.html>


More information about the postgis-devel mailing list