[gdal-dev] Improving details of the project build system and/or documentation

[Andrew C Aitchison]

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
                    andrew at aitchison.me.uk