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

Reply via email to