[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