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

[Even Rouault]

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 
> <mailto:even.rouault at spatialys.com>> wrote:
>
>     Hi,
>
>     Please find at https://github.com/OSGeo/gdal/pull/4590
>     <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 <http://www.spatialys.com>
>     My software is free, but my time generally not.
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>     <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20211004/0ec610eb/attachment.html>