CMake/MSVC Support

[Will Bowers]

Hello again All. I ended a bit busy Friday/Saturday, due to current
cybersecurity events.

Regina, thanks for the clarification on liblwgeom. That reasoning makes
sense.

Esteban: I share your sentiment. I don't _need_ PostGIS building with CMake
per se, but I do think it would be very handy. What compiler/platform are
you trying to target? I still need to look at the build pipeline you sent
me last week.

Right now I have my hacked-together changes building on MSVC for Windows;
it doesn't link yet, as I'm still getting lwgeom to build. The dependency
chain is a bit tedious - it seems to possibly require boost, which
fittingly ran my project drive out of space. *sigh*

Once I do have it working, and the source patches hopefully merged into the
PostGIS repo, I will probably release just my CMake targets and other
tooling in their own repo for your consideration.

I will open a ticket at some point, just for getting PostGIS to compile on
MSVC. I don't expect the PostGIS project to officially support CMake
anytime soon... or ever really.

Let us resolve not to solve this too quickly, lest we cause other issues
with our solution.

Will

On Sat, Jul 20, 2024 at 12:57 PM ZIMANYI Esteban <esteban.zimanyi at ulb.be>
wrote:

> Dear Will
> As you have witnessed, the issue of CMake is delicate with the PostGIS
> team ...
> If by chance you manage to do a build for your own usage, irrespective of
> whether it will arrive or not to the PostGIS code, please let us know
> because we REALLY need to be able to build PostGIS with CMake and we don't
> need to comply with all the PostGIS bots ...
> Regards
> Esteban
>
> ------------------------------
> *De :* Regina Obe <lr at pcorp.us>
> *Envoyé :* samedi 20 juillet 2024 06:30
> *À :* 'Will Bowers' <wbowers314 at gmail.com>; 'Greg Troxel' <gdt at lexort.com>
> *Cc :* 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
> *Objet :* RE: CMake/MSVC Support
>
>
> 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
> <gdt at lexort.com>*> wrote:
>
> Will Bowers <*wbowers314 at gmail.com <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.
>
> t
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20240721/79b595b4/attachment.htm>