I don't have a position - but I do think the RFC should mention which solution it is proposing.
On Mon, 4 Oct 2021 at 14:04, Even Rouault <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 > > 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> > 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@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > -- 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