[gdal-dev] CMake for GDAL

[William Kyngesburye]

Same as for your PROJ cmake effort, I can help with the OS X framework rules for GDAL. (Note: framework build is a separate thing from generating Xcode project.)

On Oct 6, 2011, at 11:04 AM, Howard Butler wrote:

> All,
> 
> There has been a couple of efforts started to bring a CMake build configuration to GDAL, but they haven't taken off because of lack of momentum and project buy in. For those who don't know, CMake is a sort of meta-builder, kind of like an autotools that generates many project Makefile layouts. CMake can generate MSVC project files, MSVC Makefiles, XCode, Eclipse, GNU Makefile, etc. You have one CMake configuration that specifies the changeable bits, and CMake takes care of the rest to generate the project type that you desire. CMake can even stack project builds together, so the the CMake configuration of GDAL can use the CMake configuration of GeoTIFF.
> 
> GDAL currently has hand-rolled MSVC Makefiles, an combination hand-rolled libtool project (that we generally tell people not to use), and hand-rolled MSVC project files.  Adding another build system into our source tree is not going to add that much more complexity to what we already have, and I would like to propose that we integrate the CMake build for GDAL efforts that have been happening outside of the project inside our source tree.  If the effort takes off, maybe we can eliminate some of these hand-rolled efforts, but at this time, the CMake effort will just be supplementary to the existing build systems that already exist in GDAL.
> 
> 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.  Aashish is a GDAL user, and a CMake configuration, with full detection capabilities for the myriad of external dependencies that GDAL can take advantage of would be a big, cross-platform build win for him. 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.  Workflow-wise, I would like to give Aashish sandbox access so he can start working on the tree there, and then I'll take care of moving things into the main trunk as they mature.  Once things are integrated, it would make lots of sense to give Aashish proper commit access provided he looks like he'll be able to stick around and help maintain things -- although once everything is standing, the maintenance should be limited. 
> 
> 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.
> 
> Thanks,
> 
> Howard_______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects."

- the wisdom of Tarzan