- 2012-04-28 - Pilot project of CMake configuration for GDAL is being developed internally by Kitware. It should be delivered soon, so stay tuned. Once first beta is released to the public, it will be available for testing, improvements
- 2012-04-19 - CMake 2.8.8 is Now Available with the OBJECT library feature.
- 2012-03-19 - Brad King from Kitware committed new CMake OBJECT feature which is fundamental for CMake configuration for GDAL. Check CMake Object Library tutorial for details.
NOTE: The discussion below may be out of date, and not reflecting the actual status. To be updated.
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.
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.
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):
- Basic configuration which determines architecture, system, building toolset, etc.
- Look for all third-party libraries used by GDAL, required and optional.
- 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.