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.roua...@spatialys.com <mailto:even.roua...@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.roua...@spatialys.com <mailto:even.roua...@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@lists.osgeo.org <mailto:gdal-dev@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.

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to