On Tue, 30 May 2023, Howard Butler wrote:
I totally agree that we would need to do some kind of cost/benefit
to see if the complexity is worth the trouble. Our experience with
PDAL is that drivers with hairy external dependencies that are
either closed source or not conveniently distributed are the best
candidates for this approach.
- offering the possibility of building just a driver as a plugin in
- a unit way would require people to build against the same GDAL
- headers as libgdal.
Does it really? If communication across the boundary of the plugin
to GDAL is using public GDAL pointers/classes/methods that haven't
changed in many releases, does the plugin version actually need to
perfectly match the main library version? For PDAL it hasn't, and we
have used older binary plugins against newer main libraries with
success. PDAL's interface in this regard is smaller, however, so the
risk of changes causing problems are less. You could also wire in
some explicit plugin versioning if you wanted a way to force a
bump. I think if this were a community desire and priority, it could
be done.
I maintain two of my own drivers and have tooling to build them
as plugins against several different versions of GDAL, so have
done a very quick test. A plugin built against 3.6.2 will run in
3.6.0 - 3.6.4 but gdalinfo 3.7.0 aborts with the message:
ERROR 1: <plugin> was compiled against GDAL 3.6,
but the current library version is 3.7
Going the other way is similar.
I am not sure what would happen if gdal did not enforce matched minor versions.
While my plugins do have some #ifdefs for different GDAL versions,
the last change was https://github.com/OSGeo/gdal/pull/6609
when 3.6 dropped compatibility function _GetProjectionRef() and friends,
which should not affect 3.6.x <-> 3.7.y.
IIRC this was the first incompatibility since 3.0.
My hunch is the ability to more easily take advantage of GDAL
plugins within various GDAL binary deployment archipelagos (conda
forge, pip, debiangis, vcpkg, homebrew, osgeo4w) would be leveraged
if it were easier to do, it reliably worked, and it didn't come with
a big performance penalty. I would love for 'pip install
rasterio[ecw]' to work and not have to be updated with every GDAL
release unless the ECW driver itself was actually updated. That
hunch could be misinformed, however, and we would need feedback and
information from the community before we should commit to changing
anything significant.
I did submit one of my drivers for inclusion with GDAL,
but I haven't yet managed to get the code up to Even's standards,
so have thought about putting it on github as a plugin, but the
number of GDAL versions times platforms I would have to package
mean I haven't explored github packages yet.
--
Andrew C. Aitchison Kendal, UK
[email protected]
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
