[gdal-dev] CMake for GDAL

[Mateusz Loskot]

On 06/10/11 17:04, Howard Butler wrote:
> CMake can even stack project builds together, so the the CMake
> configuration of GDAL can use the CMake configuration of GeoTIFF.

... and PROJ.4 soon :-)

> I am willing to manage this effort, and I expect contribution from a
> couple of folks who have been itching for it. One of these key
> individuals is someone I met at #foss4g, Aashish Chaudhary, who is a
> software engineer at Kitware, the proprietors of CMake.
 > [...]

This is a great news!

> Aashish has volunteered to do the bulk of the integration
> work of the existing, external CMake configuration into the source
> tree, and having quick access to CMake developers who can answer any
> questions that might come up about GDAL's complex build layout will
> also be helpful.

Sounds good indeed.

> tl;dr summary. Aashish Chaudhary and myself are going to bootstrap
> incorporating CMake configuration into GDAL. We hope to have things
> done by the 1.9 release. This is your notice of that fact.

Are you going to write some notes, perhaps on GDAL Wiki, about basics
of the configuration design and structure?

I've been growing the idea of CMake configuration for long time with one 
attempt that eventually failed due to the reasons you've mentioned.
My idea was to have CMake core configuration that is written once
and fairly static in long term. Then, there are several macros which 
allow driver developers and maintainers to plug-in their drivers to the
CMake configuration with literally a few lines of CMake script.

Basically, the CMake configuration could be modular.

I have implemented this approach on smaller scale while configuring SOCI 
library. It is a database access library in C++ that consists of core + 
a set of backends (drivers):

http://bit.ly/reLrPE

The modularisation separates a few things:

1)- third-party dependencies lookup follows the well-known convention
   of cmake/modules/Find*.cmake

2) selection of what is needed is configured file-based in 
cmake/dependencies - e.g. if Boost.cmake exists, then Boost is a 
dependency. This scheme uses module from 1) to search for Boost components.

3) configuration of backend (driver) library is a single call of 
soci_backend() macro, see backends/sqlite3/CMakeLists.txt.
Corresponding test is configured in similar way
backends/sqlite3/test/CMakeLists.txt

This states a minimal configuration for CMake and assumes there are
no specialised options required for this particular driver.

4) If common denominator is not enough and there are neede
some public options specific to driver, then such options go to CMake 
configuration local for this driver, see
src/backends/postgresql/CMakeLists.txt

So, there is a framework that catches all common properties for the 
drivers. The rest is moduler. If any kind of customisation is needed,
it is defined locally for particular driver.
The master/root CMakeLists.txt is lean and thin as it should be.

I am not a master of CMake, so perhaps this approach is not the best 
possible, but it works fairly well. However, assuming Aashish and his 
team know CMake better, perhaps they could suggest if this is a good 
idea, if there is a better idea, so we can discuss pros and cons.

I'm interested in contributing and testing.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org