[gdal-dev] About CMake build again

[Even Rouault]

Hi,

Trying to sum up my thoughts on this topic and answering to various points raised in this 
discussion thread:

- I believe a relevant question to ask to ourselves would be: "imagine that GDAL would come 
without any build system at all, what is the one that we would add" ? Ok, that's a bit silly to 
turn the question like that, a more realistic one would be "imagine you're going to create a 
software that will rule over the world, for the 20 next years and beyond, and should run on 
all reasonable platforms, which build system would we use? If the answer is clearly "cmake", 
then it is worth examining if there is not a path that would lead us to that point.
Similar question: is it an effort that will make GDAL development a bit easier for new 
contributors?

- Must be reasonably friendly for GDAL developers, and for GDAL users (users here = people 
building GDAL, but not actively hacking into its sources). As a user of cmake on Linux (and 
marginally on Windows), my experiences are rather good.

- the selling points I'd see with cmake would be the possibility of having ultimately a single 
build system, instead of the 2 ones we have. + solving the current lack of dependency 
tracking (speaking here about the mecanism that cause a change in a .h file to make the 
.c/.cpp files that depend on it to be automatically rebuilt). We could add that by using 
automake instead of our home-made GNUmakefile's, but doesn't feel like that's worth the 
effort by itself.
A nice side effect could also be the opportunity to drop some cruft that has accumulated 
over years in the current build systems (supporting ancient library versions that no longer 
make sense)

- If we added cmake support in trunk, I think this would only make sense if (all conditions to 
be met)
	*  we have at least a couple of "champions" to support the effort, and with an 
agreement on how to use cmake as a in-tree build solution. Regarding Borsch, I think Dmitry 
and his team did an impressive work, although I think that for GDAL we would want a more 
"traditional" way of using cmake (in-tree, no particular requirents regarding how the 
dependencies should be made). I'd hope that part of the work done on Borsch (or at the very 
least good ideas and the lessons learnt) could be ported back to such a more traditional way 
(and in a way where that would still be useful for Borsch. Possible win-win ?)
	* growing it from an experimental status to the recommended build system, once 
its completely mature. I'd expect that to require a transition over one or two release cycles 
(one reason for that delay would be that systems ship with a recent enough version of cmake 
regarding the minimum we would require)
	* ultimately removing autoconf + nmake support. Clearly we don't want to 
support 3 different build systems for the next 20 years.

- Thinking that if there's an agreement to give it a try, the next OSGeo code sprint ( https://
wiki.osgeo.org/wiki/OSGeo_Code_Sprint_2018 ) could be the opportunity to boost (no pun 
intended) the effort

- I'm puzzled about some of you having apparently completely different feeback regarding 
CMake on the same platform (MacOS). I don't owe a Mac, so I've no informed opinion on this. 
But I see that a software, with a complexity similar to GDAL, like QGIS uses CMake and it 
builds on Linux, Windows and MacOSX

- There wasn't much discussion about support for more exotic targets, like cross-compiling 
for Windows with mingw compiler hosted on Linux. But openjpeg for example has Travis-CI 
targets doing that, so this is at least achievable for a simple library.

- I've no fundamental objection to cmake... nor fundamental enthousiasm for it or mastering 
of it (could say the same about autoconf/automake or nmake. Build systems are boring 
subjects, aren't they ?)

Even

PS: for Ari, try ./configure --enanble-debug for builds with -g and without -O2 ;-)

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171030/2e482f4b/attachment.html>