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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
