Opened 11 years ago
Last modified 7 years ago
#2362 new enhancement
Support building with CMake
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS Fund Me |
Component: | build | Version: | master |
Keywords: | Cc: | Bishop |
Description
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)
Change History (18)
comment:1 by , 11 years ago
comment:2 by , 9 years ago
Milestone: | PostGIS 2.2.0 → PostGIS Future |
---|
comment:3 by , 9 years ago
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
follow-up: 7 comment:4 by , 9 years ago
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.
follow-up: 8 comment:5 by , 9 years ago
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!
comment:6 by , 9 years ago
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.
comment:7 by , 8 years ago
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.
comment:8 by , 8 years ago
Cc: | added |
---|
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.
comment:9 by , 8 years ago
By the way all repositories were moved to https://github.com/nextgis-borsch
comment:10 by , 8 years ago
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:
comment:13 by , 8 years ago
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.
comment:15 by , 8 years ago
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.
comment:16 by , 8 years ago
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.
comment:17 by , 8 years ago
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.
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.