[gdal-dev] RFC 84: Migrating build systems to CMake

[Kurt Schwehr]

I am strongly in favor of CMake for GDAL with this RFC.  I was slightly
approsed in prior proposals for CMake.

Some supporting tidbits:

   - There is much support in IDEs for CMake -
   https://gitlab.kitware.com/cmake/community/-/wikis/doc/Editors
   - 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.
   - The more I try to use autoconf, automake, and related, the more
   frustrated I get with them.
   - cmake + ninja on machines with larger number of cores is really
   awesomely fast

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".

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:

gdal_translate --formats | wc -l
21
blaze-bin/third_party/gdal/ogr2ogr --formats | wc -l
20


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.

On Mon, Oct 4, 2021 at 8:31 AM Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Le 04/10/2021 à 15:38, Paul Harwood a écrit :
>
> I don't have a position - but I do think the RFC should mention which
> solution it is proposing.
>
> I've just added one
>
>
> On Mon, 4 Oct 2021 at 14:04, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Paul,
>>
>> 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.
>>
>> 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:
>> https://github.com/miurahr/cmake4gdal/tree/master/cmakelists/gdal/swig
>>
>> Even
>> Le 04/10/2021 à 14:41, Paul Harwood a écrit :
>>
>> I am not sure if I should be posting this here or on the bug - so I am
>> starting here.
>>
>> The RFC does not mention (either positively or negatively) the SWIG
>> bindings.
>>
>> Just for the avoidance of doubt :
>>
>> - It should probably be made clear in the doc if the SWIG bindings are to
>> be included in the CMAKE build process, and
>>
>> - 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.
>>
>> Paul
>>
>> On Mon, 4 Oct 2021 at 12:49, Even Rouault <even.rouault at spatialys.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Please find at https://github.com/OSGeo/gdal/pull/4590 a RFC that
>>> proposes:
>>>
>>> - to develop a CMake build system, officially integrated in the source
>>> tree.
>>>
>>> - and remove the current GNU makefiles and nmake build systems, when the
>>> CMake build system has matured enough and reached feature parity.
>>>
>>> Best regards,
>>>
>>> Een
>>>
>>> --
>>> http://www.spatialys.com
>>> My software is free, but my time generally not.
>>>
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20211004/87739335/attachment.html>