<div dir="ltr"><font size="2">{apologies for the late response - add your preferred rif on "I was busy" excuses}</font><div><font size="2"><br></font></div><div><font size="2">The PDAL approach is much easier (speaking as the de facto C# maintainer for PDAL and MDAL).<br><br>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!</font></div><div><font size="2"><br></font></div><div><font size="2">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.</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 31 Jan 2025 at 14:18, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Le 31/01/2025 à 13:09, Paul Harwood a écrit :<br>
> The problem about "moving" the bindings is going to be that all of the <br>
> SWIG definitions for all bindings are intimately wound together. It <br>
> would be a lot of work for little gain.<br>
<br>
That intertwine is both a strength and a weakness of our bindings, in <br>
that it apparently minimizes the level of effort to have them, but it <br>
results in bindings that are neither Pythonic, Javaish (or C#'ish  ? no <br>
idea about how C# users feel about the GDAL ones), and that nobody <br>
really feels responsible about. The obvious illustration is that the <br>
casing convention one uses in the .i files for method and parameter <br>
names influences *all* bindings and obviously you can't expect all <br>
languages to agree on CamelCase, camelCase or snake_case ... Not to <br>
mention that in lots of case we just copy&paste the Hungarian convention <br>
from the C API that even most C users would dislike.<br>
<br>
I know Howard has been a long time advocate of kicking all bindings out <br>
of OSGeo/GDAL and let them flourish or perish in their standalone <br>
existence (we just chatted yesterday about that again), and he's pretty <br>
happy with how that turned out for PDAL. But I'm also not so convinced <br>
that the return on investment is high enough for GDAL (contrary to the <br>
switch to CMake where there was a significant initial cost but I was <br>
convinced that it would be a big win, which it is), especially when <br>
selfishly thinking to the Python bindings, especially given their <br>
central place in libgdal testing.<br>
<br>
><br>
> NONE of these possibilities would be a valid response to our lack of <br>
> knowledge.<br>
<br>
You're right. I saw recently a toot from another OSS maintainer who also <br>
complained he had little clue about which part of his software were <br>
used, except when people filed bugs.<br>
<br>
Options (readers: don't read all of them too literally and scream, just <br>
my current brain dump...):<br>
<br>
- add on purpose bugs to the software to know which parts are used (at <br>
least the parts where you don't know) ?<br>
<br>
- do nothing and let people feel demotivated/frustrated about <br>
maintaining the software and give up ?   Only people who don't maintain <br>
code could naively assume there is a zero cost in keeping unused code <br>
around. The cost is hard to objectivize, but it is definitely not zero. <br>
If we had to pay for the VMs of our CI, there would be a clear cost in <br>
$$ for that.  It also costs in term of time for maintainers when they <br>
develop and have to wait for a build to complete. Or when Coverity Scan, <br>
cppcheck, etc. have an upgrade in their analyzers that suddenly raise a <br>
new category of warnings. This is a sum of little something.<br>
<br>
- wait that AI finally kick out human maintainers from the equation and <br>
can deal with an ever growing code base without complaining ?<br>
<br>
- less provocative: add telemetry. obviously not opt-in because nobody <br>
would take the time to turn it on, but just opt-out<br>
<br>
Even<br>
<br>
-- <br>
<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
Grumpy maintainer.<br>
"De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac<br>
<br>
</blockquote></div>