It sounds great indeed! In particular I am interested in improving detection of netcdf library and its various incarnations and support libs (v3, v4, HDF4, HDF5, zlib, szip), which would make things much easier for our improvements to the netcdf driver.
I'd definitely like to help on that aspect of the cmake script, although I don't have experience in building cmake configuration scripts. regards, Etienne On Thu, Oct 6, 2011 at 1:04 PM, Howard Butler <hobu....@gmail.com> 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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
