<div dir="ltr">I am strongly in favor of CMake for GDAL with this RFC. I was slightly approsed in prior proposals for CMake.<div><br></div><div>Some supporting tidbits:</div><div><ul><li>There is much support in IDEs for CMake - <a href="https://gitlab.kitware.com/cmake/community/-/wikis/doc/Editors">https://gitlab.kitware.com/cmake/community/-/wikis/doc/Editors</a></li><li>As a maintainer of an out-of-tree bazel based build for GDAL, I think that it's not a good solution for GDAL. bazel is about build speed and simplicity. It makes it hard to have large numbers of selectable options beyond general compiler options. It's also fairly easy to keep my own bazel build.</li><li>The more I try to use autoconf, automake, and related, the more frustrated I get with them.</li><li>cmake + ninja on machines with larger number of cores is really awesomely fast</li></ul><div>Having folks working in the core wanting to move to CMake and the PROJ, GEOS, and others switching puts me firmly in support of this RFC. CMake, like every other build system, is definitely weird, but I agree that it's one of the "least weird".</div></div><div><br></div><div>I want to say thank you to all the folks who have worked on CMake for GDAL. Taking a quick peek at cmake4gdal, I would suggest that a lot more drivers should be switched from using gdal_format to gdal_optional_format. There are folks (e.g. me!) who prefer to have the bare minimum of drivers built. e.g. one of my builds:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace">gdal_translate --formats | wc -l</font></div><div><font face="monospace">21</font></div><div><font face="monospace">blaze-bin/third_party/gdal/ogr2ogr --formats | wc -l</font></div><div><font face="monospace">20</font></div></blockquote><div><br></div><div>And really, I should make those smaller. I know that some of the required formats are required mostly for autotest. I'd be be interested in working on getting the minimum footprint down once things are switched to CMake.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 4, 2021 at 8:31 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>Le 04/10/2021 à 15:38, Paul Harwood a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">I don't have a position - but I do think the RFC
should mention which solution it is proposing.</div>
</blockquote>
I've just added one<br>
<blockquote type="cite"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 4 Oct 2021 at 14:04,
Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Paul,</p>
<p>that's a legitimate question indeed. There have indeed
been discussions among devs if bindings would not better
leave outside of the GDAL repository and have their own
independent lives. That would conceivably be doable for
the Java or CSharp bindings. More tricky for the Python
bindings since we need them for the regression test suite.</p>
<p>Adopting a new build system is indeed the opportunity to
raise several questions about the existing structure
(folder organization, etc), but I'm afraid that if we try
to change too many things at a times, this increases the
risk of failure (or at least the time to achieve the
result). My own position would be, at least in the scope
of this RFC, to keep the bindings in the repo (excluding
the Perl ones that will be removed in GDAL 3.5, in favor
of the out-of-tree Perl FFI bindings) and build them
through GDAL's main CMake. CMake4GDAL has already support
for that: <a href="https://github.com/miurahr/cmake4gdal/tree/master/cmakelists/gdal/swig" target="_blank">https://github.com/miurahr/cmake4gdal/tree/master/cmakelists/gdal/swig</a><br>
</p>
<p>Even<br>
</p>
<div>Le 04/10/2021 à 14:41, Paul Harwood a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">I am not sure if I should be posting this
here or on the bug - so I am starting here.<br>
<br>
The RFC does not mention (either positively or
negatively) the SWIG bindings.<br>
<br>
Just for the avoidance of doubt :
<div><br>
- It should probably be made clear in the doc if the
SWIG bindings are to be included in the CMAKE build
process, and </div>
<div><br>
</div>
<div>- I ask the question, in all innocence and without
any prejudice on my behalf or even idea of what the
answer would be, since if there were to be a better
way of organising things then a major refactor of the
build process would be the correct time to implement
it.</div>
<div><br>
</div>
<div>Paul</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 4 Oct 2021 at
12:49, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Please find at <a href="https://github.com/OSGeo/gdal/pull/4590" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/4590</a>
a RFC that proposes:<br>
<br>
- to develop a CMake build system, officially
integrated in the source tree.<br>
<br>
- and remove the current GNU makefiles and nmake build
systems, when the <br>
CMake build system has matured enough and reached
feature parity.<br>
<br>
Best regards,<br>
<br>
Een<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote>
</div>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>