Hi Even, On Thu, 2 Nov 2023 at 11:59, Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote:
> > I'm seeking for feedback and review on a new RFC (RFC 96: Deferred > in-tree C++ plugin loading), detailed in > https://github.com/OSGeo/gdal/pull/8648, whose summary is: > > This RFC adds a mechanism to defer the loading of in-tree C++ plugin > drivers to the point where their executable code is actually needed, and > converts a > number of relevant drivers to use that mechanism. The aim is to allow for > more > modular GDAL builds, while improving the performance of plugin loading. > This looks great from my perspective. Are there any downsides? 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. Rob :)
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev