Hi all, I am working with CMake configuration as developer few years, can I help as tester & contributor?
On 10/06/11 18:04, 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
