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

[Paul Harwood]

{apologies for the late response - add your preferred rif on "I was busy"
excuses}

The PDAL approach is much easier (speaking as the de facto C# maintainer
for PDAL and MDAL).

However - it is a real "I would not start from here" issue (to quote our
Irish cousins). I cannot see the communities in question putting in the
work - especially since they do not see anything as broken!

At the very least, this is an RFC issue. I could, for instance, see a
solution (which, like all compromises, would please no one) where the
binding-specific code, tests, compilation scripts, and CI are contained in
dedicated repos, but the common SWIG include scripts would remain within
the GDAL repo.

On Fri, 31 Jan 2025 at 14:18, Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Le 31/01/2025 à 13:09, Paul Harwood a écrit :
> > The problem about "moving" the bindings is going to be that all of the
> > SWIG definitions for all bindings are intimately wound together. It
> > would be a lot of work for little gain.
>
> That intertwine is both a strength and a weakness of our bindings, in
> that it apparently minimizes the level of effort to have them, but it
> results in bindings that are neither Pythonic, Javaish (or C#'ish  ? no
> idea about how C# users feel about the GDAL ones), and that nobody
> really feels responsible about. The obvious illustration is that the
> casing convention one uses in the .i files for method and parameter
> names influences *all* bindings and obviously you can't expect all
> languages to agree on CamelCase, camelCase or snake_case ... Not to
> mention that in lots of case we just copy&paste the Hungarian convention
> from the C API that even most C users would dislike.
>
> 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.
>
> >
> > NONE of these possibilities would be a valid response to our lack of
> > knowledge.
>
> You're right. I saw recently a toot from another OSS maintainer who also
> complained he had little clue about which part of his software were
> used, except when people filed bugs.
>
> Options (readers: don't read all of them too literally and scream, just
> my current brain dump...):
>
> - add on purpose bugs to the software to know which parts are used (at
> least the parts where you don't know) ?
>
> - do nothing and let people feel demotivated/frustrated about
> maintaining the software and give up ?   Only people who don't maintain
> code could naively assume there is a zero cost in keeping unused code
> around. The cost is hard to objectivize, but it is definitely not zero.
> If we had to pay for the VMs of our CI, there would be a clear cost in
> $$ for that.  It also costs in term of time for maintainers when they
> develop and have to wait for a build to complete. Or when Coverity Scan,
> cppcheck, etc. have an upgrade in their analyzers that suddenly raise a
> new category of warnings. This is a sum of little something.
>
> - wait that AI finally kick out human maintainers from the equation and
> can deal with an ever growing code base without complaining ?
>
> - less provocative: add telemetry. obviously not opt-in because nobody
> would take the time to turn it on, but just opt-out
>
> Even
>
> --
>
> http://www.spatialys.com
> My software is free, but my time generally not.
> Grumpy maintainer.
> "De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250217/16504810/attachment.htm>