[gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

[Momtchil Momtchev]

On 31/01/2025 23:31, Howard Butler via gdal-dev wrote:
> On Jan 31, 2025, at 8:18 AM, Even Rouault via gdal-dev 
> <gdal-dev at lists.osgeo.org> wrote:
>
> 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.


In 2025 SWIG still has no alternatives. It is surely dated and it may be 
time to think about a successor project, but currently I am not aware of 
anyone actually working on it.

Recently there has been a new way to do it, pioneered by Boost and made 
very popular by the pybind11 project. This same approach has been copied 
by embind in emscripten/WASM and I also have my own nobind17 for 
Node.js. Even if these are much faster to learn and easier to maintain - 
because they do not require a special and very awkward specific language 
- everything is only C++ - they lack many of the advanced features that 
allow a very large library such as GDAL to have a fully native feel  - 
especially one that has not been designed from scratch to be used from a 
higher-level language.

Surely the 100% handwritten bindings - such as PDAL for C# or GDAL for 
Node.js or Julia - have their advantages, but the development cost is 
orders of magnitude higher. If I was to start GDAL for Node.js from 
scratch, I was surely going to use SWIG. Both GDAL for Node.js and GDAL 
for Julia use handwritten code because at the time of their creation, 
SWIG did not have good support for those languages. PDAL's API is orders 
of magnitude smaller than GDAL and it has been designed to be used from 
a higher-level language.

I personally think that the future belongs to a project that will use 
the LLVM front-end and produce pybind11-like code, but this project does 
not exist. NativeScript is going in this direction for JavaScript, but 
they too, they lack many of the advanced SWIG features.

Now, of course, if there is no one to work on GDAL for C#, there is 
nothing to be done. It is unlikely there will ever be onboarding for 
this, as its cost is far too great for something that probably will be 
used only once. I am afraid that there are no real alternatives besides 
SWIG.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250201/e28467ba/attachment.htm>