Support building with CMake

[robe]

It's becoming clear that building PostGIS with cmake is a direction we need to move. There are a couple of environmental pressures driving us to this need

1) A good portion of OSGeo software already supports CMake — GEOS, MapServer, pgRouting (and even stuff that is psuedo PostGIS core: SFCGAL and upcoming postgis_pointcloud)

2) We've already got cmake in being injected into our blood: sfcgal, pointcloud, pdal, pgrouting all require cmake

3) We need to start supporting VC++ to ensure compatibitily with EDB builds (I still question this argument)? and just in case there are creatures out there who want to compile with VC++ (seems to be ironically all Linux folks)

[robe]

For reference mloskot has put in a lot of effort into this move

​https://github.com/mloskot/postgis/tree/cmake-build

So we really should start giving it a go: Excerpt from email between Mat, Dave Page, and other poor saps I dragged into this conversation.

On 4 June 2013 18:58, Dave Page wrote:
>> Dave,
>>
>> Sorry for harping at you.  As you can see I think there is definite 
>> community interest if nothing more than to make debugging easier, but 
>> that said it would be nice if we don't have a secondary 
>> infrastructure we have to constantly babysit. Cmake does seem like 
>> the easiest route to take especially since a lot of GIS software has already standardized on it.
>
> Agreed, Cmake does seem like the best option.

FYI, I've done another round of updating cmake-build branch with changes from svn-trunk, looks I had to do proper git merge:
https://github.com/mloskot/postgis/tree/cmake-build

Also added some small improvements for postgis_svn_revision.sh.

Unfortunately, postgis.sql.in.c and friends have been changed to w/o .c and seems like new processing is now required - no idea what's new there.
This means, the custom preprocessing commands need to be reviewed.
If I have time, I will give it a go, but ATM I've got too much on plate.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

[Bishop]

I rewrote most of Mateusz cmake scripts and added some additional features:

• utilities
• raster, topology and address_standardizer
• fixes and improvements

The SFCGAL, tiger geocoder and bindings are not cmaked by now.

The new cmake scripts for PostGIS 2.2.2 are available here: ​https://github.com/nextgis-extra/postgis The cmaked postgis builds are available in this ppa: ​https://launchpad.net/~nextgis/+archive/ubuntu/ppa/+packages

Please note, the build was not tested on Windows. But it seems to me, that few problems maybe here:

• dependency on Perl (I remove a lot of Perl stuff, but some critical Perl scripts are left)
• Postgres extension and contrib folders path detection on Windows
• Postgres developer package analog

[pramsey]

Perl stuff was actually done largely in service of Windows, since on windows access to things like "sh" and "sed" are not guaranteed, whereas perl provides a pretty platform independent source of file munging and regex. If you've folded perl stuff right into cmake, then all well and good, but if you're counting on unix tools, then not so much.

[robe]

It's about time I upgraded anyway so not a big deal. Just wondering if it would be an issue on other platforms. I have cmake 2.8.11 and first message I get out of the gate is:

CMake Error at CMakeLists.txt:7 (cmake_minimum_required):
  CMake 2.8.12 or higher is required.  You are running version 2.8.11


-- Configuring incomplete, errors occurred!

[robe]

I think GEOS detection needs some work. It doesn't like my GEOS 3.5.0 yet it does find it.

CMake Error at C:/ming64gcc48/cmake-3.5.2-win32-x86/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find GEOS: Found unsuitable version "", but required is at least
  "3.4" (found
  C:/ming64gcc48/projects/geos/rel-3.5.0w64gcc48/lib/libgeos_c.dll.a)
Call Stack (most recent call first):
  C:/ming64gcc48/cmake-3.5.2-win32-x86/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindGEOS.cmake:162 (find_package_handle_standard_args)
  cmake/FindAnyProject.cmake:82 (find_package)
  CMakeLists.txt:154 (find_anyproject)

I tried swithching to my GEOS 3.4.2 build and it didn't like that either:

PATH AFTER: /projects/gtkw64gcc48/bin:/projects/geos/rel-3.4.2w64gcc48/bin:/projects/gdal/rel-2.1.0w64gcc48/bin:/projects/rel-libiconv-1.13.1w64gcc48/lib:/projects/rel-libiconv-1.13.1w64gcc48/include:/projects/rel-lib
Already up-to-date.
-- ←[1;33mpostgis version 2.2 USE_GEOS=1 USE_PROJ=1 USE_STATS=1←[m
--
-- ←[1;4;34mConfiguring PostGIS:←[0m
--
-- Found PostgreSQL: C:/ming64gcc48/projects/postgresql/rel/pg9.6w64gcc48/lib/libpq.dll (found suitable version "9.6devel", minimum required is "9.1")
-- Performing Test ICONV_HAVE_WERROR
-- Performing Test ICONV_HAVE_WERROR - Success
-- Performing Test ICONV_SECOND_ARGUMENT_IS_CONST
-- Performing Test ICONV_SECOND_ARGUMENT_IS_CONST - Failed
-- Found Iconv: C:/ming64gcc48/projects/rel-libiconv-1.13.1w64gcc48/lib/libiconv.dll.a
-- Found PROJ4: C:/ming64gcc48/projects/proj/rel-4.9.1w64gcc48/lib/libproj.dll.a (found suitable version "4.9.1", minimum required is "4.6")
CMake Error at C:/ming64gcc48/cmake-3.5.2-win32-x86/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find GEOS: Found unsuitable version "", but required is at least
  "3.4" (found
  C:/ming64gcc48/projects/geos/rel-3.4.2w64gcc48/lib/libgeos_c.dll.a)
Call Stack (most recent call first):
  C:/ming64gcc48/cmake-3.5.2-win32-x86/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindGEOS.cmake:162 (find_package_handle_standard_args)
  cmake/FindAnyProject.cmake:82 (find_package)
  CMakeLists.txt:154 (find_anyproject)


-- Configuring incomplete, errors occurred!
See also "C:/ming64gcc48/projects/postgis/branches/2.3cmake/CMakeFiles/CMakeOutput.log".
See also "C:/ming64gcc48/projects/postgis/branches/2.3cmake/CMakeFiles/CMakeError.log".

I'm building under mingw64-w64 and I built GEOS with CMake. The others it detected correctly I built using standard autotools chain.

[Bishop]

Replying to pramsey:

If you've folded perl stuff right into cmake, then all well and good, but if you're counting on unix tools, then not so much.

There is no Unix specific stuff (sed, grep, sh, etc.) in my CMake scripts - only CMake functions and some Perl, as I noted.

[Bishop]

Replying to robe:

It's about time I upgraded anyway so not a big deal. Just wondering if it would be an issue on other platforms. I have cmake 2.8.11 and first message I get out of the gate is

Yes, you right, the minimal CMake version set to 2.8.12 as this version is default on most Linux distros. As CMake now 3.x it seems to me 2.8.12 is OK. But 2.8.11 or less may be tested.

About libGEOS - I noted that on Windows not tested - this mean mingw and cygwin too. Also there are some CMake keys to get lost dependencies - i.e. -DWITH_GEOS_EXTERNAL=ON (the -DWITH_GEOS=ON mast be set too). In such case the latest libGEOS will be downloaded and build.

Anyhow patch for GEOS detection under mingw is welcome.

[Bishop]

By the way all repositories were moved to ​https://github.com/nextgis-borsch

[vmo]

I took mloskot branch and I'm working on a windows build with msvc. If anyone is intersted, there is as WIP merge request there:

​https://gitlab.com/postgis/postgis/merge_requests/2

[strk]

Make sure to signal here when the PR is ready for merge please

[vmo]

strk, I will for sure.

[bishop]

Hardcoded paths in cmake

​https://gitlab.com/Oslandia/postgis/blob/cmake/cmake/modules/FindGEOS.cmake#L20

​https://gitlab.com/Oslandia/postgis/blob/cmake/cmake/modules/FindPROJ4.cmake#L20

Is it ok using osgeo4w only? Also don't see CGAL.

[robe]

No it's not okay.

[vmo]

bishop, robe, I'm happy to see some are interested.

Of course I konw an hardcoded value there is a no go. It's not even osgeo4w specific, but my machine specific. I'll need to have FindPROJ4.camke accept a custom, optional, environment variable or something to do that kind of things cleanly.

But before that I need to test everything is working. It's WIP and my MR + intervention here is to make people aware that work is in progress, not to get detailed review on temporary hacks

Right now postgis is compiling and linking, I need to do some tests, so my next priority are the extension scripts (cpp whatever | perl | sed).

For CGAL and rasters, I'm not sure I'll be able to do that right away. But it'll definitely be there at the end.

[bishop]

My solution (some outdated now as it was for PostGIS 2.2.2) based on NextGIS Borsch resolve most dependency and compiler specific issues. Why not improve it and reinventing the wheel? It fully cross-platform (Windows, Linux and Mac OS). Recently we added CGAL to Borsch (​https://github.com/nextgis-borsch/lib_cgal) - just needed one line in CMakeLists.txt to use CGAL in PostGIS CMake build.

[vmo]

bishop, as I mentioned, I started from mkslot branch, not from scratch, asked on IRC, posted here… to avoid reinventing the wheel and making more work for me than strictly necessary.

I decided against borsh when doing that. Using borsh would add a specific build dependency to PostGIS, which should be a decision made with consensus, and requires discussions, hence time. I went what seemed the shortest path that could lead to a functional build.

This ticket did not move for a year, and from the things I found out in the code, I doubt anyone has compiled postgis with msvc for some time. If I'm mistaken, please tell me, that's the aim of the post here.

If there is interest of the postgis community to move to and/or maintain cmake build, with or without borsh, someone tell me, I'll try and cover the extra mile to have a clean setup easier to maintain. If there are major argument for borsh .vs. plain cmake, we will try to take them into account, but let's do it step by step.

Please keep in mind that windows builds are a pain to setup and maintain. What I would rather need is pragmatic support and concrete help while I do my best to get this issue sorted.

[robe]

Milestone renamed