clang.jl is a very feature-light pybind11-style wrapper generator. It
does not support C++, objects, inheritance, overloading, type
downcasting and upcasting, iterators, n:m argument mapping, exceptions
and many other advanced features. It even lacks interaction with the
garbage collector relying on the user manually freeing the returned C
data structures. All these features would require extensive manual
wrapping work to implement. This is the major strength of SWIG - because
you can implement those advanced features with minimal amount of work if
you are willing to accept its very steep learning curve.
I don't use Julia, but I can still see that GDAL.jl is far below the
level of the Python bindings which I know quite well. There is a higher
level API built on top of it - ArchGDAL.jl - but it seems to be
completely handwritten.
On 01/02/2025 23:45, Joaquim Manuel Freire Luís wrote:
* Surely the 100% handwritten bindings - such as PDAL for C# or GDAL
for Node.js or Julia
Hi,
Just a small clarification, the Julia bindings are a 100% automatic
creation and cost very little, when one knows how to do it.
Joaquim
*From:*gdal-dev <gdal-dev-boun...@lists.osgeo.org> *On Behalf Of
*Momtchil Momtchev via gdal-dev
*Sent:* Saturday, February 1, 2025 10:09 PM
*To:* gdal-dev@lists.osgeo.org
*Subject:* Re: [gdal-dev] CSharp bindings queued for removal (was Re:
GDAL CSharp bindings maintainers/contributors listening... ?)
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@lists.osgeo.org> <mailto:gdal-dev@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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
