[gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Even,

31.10.17 1:14, 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?
This is clearly for me long ago and this is CMake.
>
> - 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.
Again want to point about illogical structure of source codes where we 
have some drivers in root folder (frmts)  and other drivers are deeper 
in the sources tree (ogr/ogrsf_frmts). And also we have raster drivers 
in ogrsf_frmts - like gpkg, cad (yes I know that they are raster-vector 
drivers) and vector drivers are in raster folder frmts, etc.
>
> - 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)
+ 1
>
> - 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 ?)
Using the find_anyproject function from Borsch (which is a wrapper 
around find_package) instead of find_package this is the only one 
requirements for successfully used in Borsch without any hacks (can be 
discussed to get win-win). Any others, like conventions about install 
paths, versions, naming etc. are optional and can be discussed too.
> 	* 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 ;-)
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
I working on CMake for GDAL for a long time and ready and willing to 
take part in this work. But it is necessary to make all decisions about 
how new build system based on CMake should looks like. Now it is not 
clear to me.
Should it be RFC based on this letter and 
https://trac.osgeo.org/gdal/wiki/CMake or something else?

Best regards,
     Dmitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171031/eb3d88ac/attachment-0001.html>