> On Nov 2, 2023, at 6:59 AM, Even Rouault via gdal-dev
> <gdal-dev@lists.osgeo.org> wrote:
>
> Hi,
>
> 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 is material only for GDAL 3.9 of course)
😍😍😍
IMO this has been needed for a while. I'm glad you've been able to come to a
solution that doesn't significantly impact behavior or performance.
I would like to see some language that describes the expectations for version
compatibility of plugins (ie, what happens with a plugin built against x.0 is
used against a main library of y.0).
I'm very interested to hear from packagers about this topic and whether or not
a plugin model like this is desirable to address GDAL's large dependency
challenge.
Howard
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
