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

[Even Rouault]

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 
> <mailto: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
>     <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  <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.

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