[postgis-devel] PostGIS 3 and MobilityDB

[Esteban Zimanyi]

Many thanks Regina !

On Mon, Jul 19, 2021 at 11:06 PM Regina Obe <lr at pcorp.us> wrote:

> 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 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")
> --> message(FATAL_ERROR "Could not find 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> 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.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210720/fb95a48d/attachment-0001.html>