On Jan 31, 2025, at 8:18 AM, Even Rouault via gdal-dev <gdal-dev@lists.osgeo.org> wrote: > > I know Howard has been a long time advocate of kicking all bindings out of > OSGeo/GDAL and let them flourish or perish in their standalone existence (we > just chatted yesterday about that again), and he's pretty happy with how that > turned out for PDAL. But I'm also not so convinced that the return on > investment is high enough for GDAL (contrary to the switch to CMake where > there was a significant initial cost but I was convinced that it would be a > big win, which it is), especially when selfishly thinking to the Python > bindings, especially given their central place in libgdal testing.
Back in the day, Frank had used one of the first versions of SWIG to make a GDAL Python binding, SWIG itself diverged from that, and he hand rolled it for a number of years afterward. Sean Gillies and Kevin Ruland and I showed up clamoring for new features, and the end result of that effort was the "next gen" bindings that were fully driven by modern-at-the-time SWIG and the typemap system we have today. This allowed the other language bindings to start introducing their own typemaps and conveniences. Over the years, Even Rouault and others have done tons of work to improve them. The SWIG bindings have evolved through twenty years of evolution and release to be an entire additional software project that lives inside of GDAL. The convenience of a single distribution channel for the bindings was quickly taken advantage of, especially in regard to the Python version's usage in libgdal testing. There are some big downsides to the current arrangement, and language-specific rot and unkept promises are two of the most frustrating. The onboarding process for someone wanting to contribute GDAL's SWIG binding improvements for a language is miserable, and GDAL ends up being responsible for installer complexity of every language's distribution approach. My experience with GDAL informed what we did with PDAL. The first thing was to not use SWIG. Lessons were learned, as they say :) The approach of a single unified language binding generator was in fashion in the 1990s at the same time as using UML to automatically write software. History has shown both of these things to have frustrating consequences. The second thing was to move the bindings out of the main tree. They were initially released together as GDAL is now, but we moved them out so each could be released on its own schedule independently from the main library and flourish or wither on its own. This meant a language's binding could be managed by individuals who actually had domain knowledge about it without worrying about all of the overhead of the main library's project. Is it too late to do this for GDAL? The active contributor and packaging community should make that decision, but I will say the current configuration reinforces the situation where one person ends up knowing all about it and getting stuck with its responsibility. It is very difficult drive-by patch and improve the current bindings, because those persons need to be SWIG-capable, know the language they care about, *and* be steeped in GDAL's custom build and deployment. Dan made excellent headway on it in the past couple of years, but that was just on the Python stuff, not typemaps and language'isms for every other binding. Contributions in one language exacerbate the rot and unkept promises for the others. And then there is the problem of documentation and distribution of that for each binding ... Even with the funding the GDAL Sponsorship Program provides, there are things in the GDAL project that are not sustainable. IMO, the current bindings approach is one such topic. The discussion about killing known-to-be-dead format support is another. The old build system was definitely one too, but it was not controversial how to move forward to address it. Howard
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
