<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Even,<br>
</p>
<div class="moz-cite-prefix">31.10.17 1:14, Even Rouault пишет:<br>
</div>
<blockquote type="cite" cite="mid:2354612.titQqOS24Y@even-i700">
<pre wrap="">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?</pre>
</blockquote>
This is clearly for me long ago and this is CMake. <br>
<blockquote type="cite" cite="mid:2354612.titQqOS24Y@even-i700">
<pre wrap="">
- 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.</pre>
</blockquote>
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.
<blockquote type="cite" cite="mid:2354612.titQqOS24Y@even-i700">
<pre wrap="">
- 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)</pre>
</blockquote>
+ 1<br>
<blockquote type="cite" cite="mid:2354612.titQqOS24Y@even-i700">
<pre wrap="">
- 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 ?)</pre>
</blockquote>
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. <br>
<blockquote type="cite" cite="mid:2354612.titQqOS24Y@even-i700">
<pre wrap="">
* 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 ( <a class="moz-txt-link-freetext" href="https://">https://</a>
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 ;-)
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
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. <br>
Should it be RFC based on this letter and
<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/wiki/CMake">https://trac.osgeo.org/gdal/wiki/CMake</a> or something else?<br>
<pre class="moz-signature" cols="72">Best regards,
Dmitry</pre>
</body>
</html>