CMake

This page is dedicated to discuss details of proposal, design and implementation of ​CMake configuration for GDAL.

In 2009, idea of CMake for GDAL was ​roughly discussed by Emmanuel Christophe and eventually a prototype project had launched at ​http://code.google.com/p/gdal-cmake/ but suspended a few months later and the project disappeared from Google Code. The CMake adoption for OSGeo/FOSS4G projects continued with very good results, for example QGIS, libLAS, GEOS, GeoTIFF as well as FOSS in general (KDE, clang). So, the idea of CMake configuration for GDAL was ​still alive in the community.

At FOSS4G 2011, the CMake for GDAL received some attention with follow-up on the mailing list ​announcing CMake For GDAL may get potential support from ​Kitware.

CMake is a highly capable cross-platform build system. It is a meta-build system able to generate native build configurations for number of development toolsets on variety of platforms. CMake configuration would be very beneficial for GDAL users and developers. Let get the thing done.

Brainstorm

Mateusz Loskot

I suggested ​modular approach and presented CMake for ​SOCI project as a proof of concept.

The basic idea is outlined below:

• GDAL is formed of core implementation and large number of configurable modules (drivers).
• GDAL depends on large number of third-party software libraries.
• There is 1:1 dependency between GDAL driver and third-party library. Many drivers share common dependencies like zlib or libjpeg libraries.
• I suggest to divide configuration into three steps (see SOCI approach):
  1. Basic configuration which determines architecture, system, building toolset, etc.
  2. Look for all third-party libraries used by GDAL, required and optional.
  3. Depending on results of the step 2., switch on/off building of GDAL features and drivers.
• If any of GDAL dependencies (third-party libraries) are explicitly switched off, then relevant lookup in step 2. is skipped.
• If any of GDAL features or drivers are explicitly switched off, then it does not affect lookup in step 2. but only decisions in step 3. Means, lookup of corresponding dependencies is performed.
• This way we don't care about solving the whole graph dependencies.
  • For example, if user switches off JPEG driver, We don't want to have to check: are there any other drivers enabled that depend on libjpeg? Shall we turn off libjpeg lookup?
  • Disabling a driver is decision that solely affects step 3. but does not affect any part of step 2.
  • But, configuration choices by user which switch off/on dependencies lookup in step 2. will do affect checks performed in step 3. automatically.
  • For example, if user switches off libjpeg, then all features and drivers depending on JPEG support will be switched off automatically in step 3.