[gdal-dev] Motion: adopt RFC 96: Deferred C++ plugin loading

[Sean Gillies]

Sounds good to me, Even. Rasterio's wheels can remain at the forefront of
terrible for now.

On Thu, Nov 16, 2023 at 5:10 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi Sean,
> >
> > I think this makes great sense for the project. I don't yet understand
> > what it means for an enterprise like Rasterio's PyPI wheels.
>
> I'd say it probably changes nothing. The RFC just postpones the time
> where the plugins are loaded, but the fact that they are dlopen()'ed
> (early or late) probably makes them non discoverable by delocate, since
> libgdal doesn't link to them in a way that is advertised in its shared
> library metadata. If your plan is to still have a rasterio wheel with a
> monolithic GDAL, then you don't need to build GDAL drivers as plugins
> and this RFC doesn't change anything to the status quo.
>
> I'm not familiar at all with the wheel Python packaging tools, but if
> you'd want to have GDAL plugins in separate package(s) then you'd need
> to have a way of having the gdal_XXX.so / ogr_XXX.so be put in some
> known location that can be advertized to libgdal core with
> GDAL_DRIVER_PATH.
>
> Even
>
>

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231116/6e26a5e0/attachment.htm>