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.
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
