Yes, clang.jl only supports C but you make it sound as if it was a very limited
product. But it’s not. Right, wrapped libraries need different amounts of
handwritten code, and care must be taken on managing the memory owners and when
it can be freed without crashing. ArchGDAL has a lot of code that was made in
response to interaction with other Julia packages and to make upper level
functions.
I don’t use Python, but from what I’ve seen all Python bindings examples can be
reproduced in Julia. And more, in the Julia GMT wrapper (GMT.jl) I picked some
parts of ArchGDAL and extended to wrap the most used GDAL CLI programs
(gdaltranslate, gdalwarp, ogr2ogr, etc…)
Online (and the only so far 😊) help for gdalwap
help?> gdalwarp
gdalwarp(indata, options=String[]; dest="/vsimem/tmp", kwargs...)
Image/Grid reprojection and warping function.
Args
––––
• indata: Input data. It can be a file name, a GMTgrid or GMTimage object
or a GDAL dataset
• options: List of options. The accepted options are the ones of the
gdal_translate utility. This list can be in the form of a vector
of strings, or joined in a single string. The accepted options are the
ones of the gdalwarp utility.
• kwargs: Besides what was mentioned above one can also use meta=metadata,
where metadata is a string vector with the form "NAME=...."
for each of its elements. This data will be recognized by GDAL as
Metadata. The kwargs may also contain the GMT region (-R), proj
(-J), inc (-I) and save=fname options.
Returns
–––––––
A GMT grid or Image, or a GDAL dataset (or nothing if file was writen on
disk).
From: Momtchil Momtchev <momtc...@momtchev.com>
Sent: Sunday, February 2, 2025 3:23 PM
To: Joaquim Manuel Freire Luís <jl...@ualg.pt>; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp
bindings maintainers/contributors listening... ?)
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:
1. 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><mailto: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<mailto: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
