
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Nov 2, 2023, at 6:59 AM, Even Rouault via gdal-dev <gdal-dev@lists.osgeo.org> wrote:</div><br class="Apple-interchange-newline"><div><div>Hi,<br><br>I'm seeking for feedback and review on a new RFC (RFC 96: Deferred in-tree C++ plugin loading),<br>detailed in https://github.com/OSGeo/gdal/pull/8648, whose summary is:<br><br>This RFC adds a mechanism to defer the loading of in-tree C++ plugin drivers to<br>the point where their executable code is actually needed, and converts a number<br>of relevant drivers to use that mechanism. The aim is to allow for more modular<br>GDAL builds, while improving the performance of plugin loading.<br><br>(This is material only for GDAL 3.9 of course)<br></div></div></blockquote></div><br><div><span style="font-size:-webkit-xxx-large" class="AppleMailBigEmoji">😍😍😍</span></div><div>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. </div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Howard</div></body></html>