CMake/MSVC Support

[Regina Obe]

Will,

 

When strk had the bright idea to share liblwgeom with the world, we did set it to be linked.

This caused issues though cause we would then find new versions of postgis linking to older versions of liblwgeom and then other projects starting to use it too which meant we now had a whole set of new concerns like having to care about when we changed internal machinery in a micro version of PostGIS.

 

So we decided to close it off again.  The reason it’s a separate folder is because it is a core part of most of the extensions that are part of postgis project.

 

postgis, postgis_raster, postgis_topology, postgis_sfcgal, and even sadly our commandline tools all need it and package a static copy of it for their lib/executable.

 

 

 

From: Will Bowers <wbowers314 at gmail.com> 
Sent: Friday, July 19, 2024 12:49 PM
To: Greg Troxel <gdt at lexort.com>
Cc: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: CMake/MSVC Support

 

Hi again all, thanks for all the additional info.

Greg, I hear you loud and clear. I am not trying to tell you to switch off your current build pipeline, I just want to see CMake supported as well. Maybe that support needs to be unofficial, and I am okay with that. I am of the opinion that PostGIS should build with all major compilers though, so I would love to help get it building on MSVC (with any build system).

Sandro, I am definitely confused here. But if the lwgeom that builds into PostGIS is not a fork, why is there an liblwgeom folder with all the source files in the postgis repo? Why build it as part of PostGIS instead of simply linking against it as you do with other libraries?

Will

 

On Thu, Jul 18, 2024, 5:17 PM Greg Troxel <gdt at lexort.com <mailto:gdt at lexort.com> > wrote:

Will Bowers <wbowers314 at gmail.com <mailto:wbowers314 at gmail.com> > writes:

> Thanks for the info. Like anyone else, I have personal opinions about CMake
> and Meson, but those aren't terribly important right now. There are some

I have some historical info in a broad brush way.   There have been a
lot of projects that use autoconf/automake and people show up and say
"cmake is better!  Let's switch!".  There is a "but we have to have no
regressions from current behavior" and the cmake people agree, and then
cmake support appears and it has regressions.  Typically they are in
cross build support and in working on platforms the authors haven't
tested on because at least for those implementations, they lacked the
"feature tests only, do not ever  check for a specific OS rule".

So my view, which doesn't officially count, is that to be merged any
cmake support must be:

  as free of "ifdef FooOS" as the previous system

  capable of building cross, just like autoconf

  support all the --bindir/--libdir stuff that autoconf does

  support proper -R and ld flags like autoconf/libtool does

  support building the code and running tests, with it testing the
  just-build code *even if there is a previous version installed*.

I think you will find it harder than it seems.

Making small fixes to improve portability is of course a separate
matter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20240720/1583ef71/attachment.htm>