Hi All, <div><br></div><div>First of all, many thanks to Howard for introducing me. I have been using GDAL for long time and used it successfully in various projects </div><div><br></div><div>No need to say that CMake has been adopted by various open source and commercial projects. CMake itself is open source with a very flexible licensing and is very active project (just this week 2.8.6 has been released) (<a href="http://www.vtk.org/Wiki/CMake_Projects">http://www.vtk.org/Wiki/CMake_Projects</a>)</div>
<div><br></div><div>I personally felt that GDAL can be benefited by using CMake. Once done, It will make it easier to add new modules to GDAL and save bunch of time writing custom build files for various platforms. Also if desired, can be coupled with CTEST and CDASH for testing. </div>
<div><br></div><div>It is good to see that people are supporting the idea. To know more about CMake please visit <a href="http://cmake.org/cmake/project/about.html">http://cmake.org/cmake/project/about.html</a>. Please feel free to contact us if you have any questions / concerns. </div>
<div><br></div><div>Thanks,</div><div>Aashish</div><div><br></div><div><br></div><div><div class="gmail_quote">On Thu, Oct 6, 2011 at 3:38 PM, Etienne Tourigny <span dir="ltr"><<a href="mailto:etourigny.dev@gmail.com">etourigny.dev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It sounds great indeed!<br>
<br>
In particular I am interested in improving detection of netcdf library<br>
and its various incarnations and support libs (v3, v4, HDF4, HDF5,<br>
zlib, szip), which would make things much easier for our improvements<br>
to the netcdf driver.<br>
<br>
I'd definitely like to help on that aspect of the cmake script,<br>
although I don't have experience in building cmake configuration<br>
scripts.<br>
<br>
regards,<br>
<font color="#888888">Etienne<br>
</font><div><div></div><div class="h5"><br>
On Thu, Oct 6, 2011 at 1:04 PM, Howard Butler <<a href="mailto:hobu.inc@gmail.com">hobu.inc@gmail.com</a>> wrote:<br>
> All,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thanks,<br>
><br>
> Howard_______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br></div>