[gdal-dev] Call for review and discussion on RFC96: Deferred in-tree C++ plugin loading
Even Rouault
even.rouault at spatialys.com
Thu Nov 2 06:54:39 PDT 2023
Hi Rob,
>
> This looks great from my perspective. Are there any downsides?
- A bit of additional coding complexity for driver development, but not
that much
- As mentioned in the backwards compatibility paragraph, for people
doing multi-step builds to build first libgdal and then plugins, that
will require extra care and defining the
-DGDAL/OGR_DECLARE_DRIVER_xxxx_FOR_LATER_PLUGIN. Like the condaforge
build recipee, but I would expect this to be more the exception, than
what most distributions do. The recommended approach is still to do a
single build and dispatch the artifacts in separate installable packages
afterwards
>
> I guess conceptually "Driver X depending on LibW clashes with Driver Z
> depending on LibY" cases are less likely to be hit during unit
> testing, since a particular test-runner/process won't (eventually) be
> loading the full set of drivers + dependencies? Usually that's a LibW
> vs LibY problem though, not a GDAL issue.
Yes that could somehow hide such issues, but as you said, there are
integration issues, and GDAL can't be expected to reliably detect those.
Clashes also happen generally at runtime, when you used clashing
drivers. Just loading the libraries isn't sufficient per se to run into
the clashes. At least in most situations on Linux.
I've considered yet-another config option like
GDAL_DEFERRED_PLUGIN_LOADING=NO to disable the new behaviour (meaning to
fully load the drivers at GDALAllRegister() time), but didn't go for it
for now as the use cases for it are not obvious. People wanting to
emulate it can just loop through drivers and call GetMetadata() on them,
which will force plugin loading, to simulate that.
>
> Rob :)
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231102/3f30a5aa/attachment-0001.htm>
More information about the gdal-dev
mailing list