<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>The OSGeo code sprint last week has been the opportunity to
advance the candidate implementation of the RFC. It is now
available at <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/8695">https://github.com/OSGeo/gdal/pull/8695</a> :</p>
<ul dir="auto">
<li>All drivers that can be built as plugins and depend on
external libraries have been converted to use the deferred
plugin loading capability. Plus a few other drivers that only
depend on core</li>
<li>The PNG, JPEG, GIF, MRF, NITF and planetary (PDS, PDS4, ISIS2,
ISIS3, VICAR) drivers can also now be built as plugins (when not
using the in-tree vendored libraries such as libpng, libjpeg,
etc.), and use deferred plugin loading</li>
</ul>
<p>On my full configuration with all drivers that can be built as
plugins effectively built as plugins - that is those that only
depend on libgdal, with -DGDAL_ENABLE_PLUGINS_NO_DEPS=ON and those
that depend on third-party libraries, with
-DGDAL_ENABLE_PLUGINS=ON -, the initialization time has dropped
from ~ 300 ms to 70 ms. If building only as plugins drivers that
depend on third-party libraries with -DGDAL_ENABLE_PLUGINS=ON
(which is the config that makes most sense), it drops to 26 ms,
with all 55 plugins in deferred loading mode. One of the biggest
culprit identified during the conversion process was the DGNv8 /
DWG driver wich links to gazillion shared libraries of the Teigha
SDK.</p>
<p>I've also added a bit of extra user friendliness:<br>
</p>
<p> When a plugin driver is known of core libgdal, but not
available as a plugin at<br>
runtime, GDAL will inform the user that the plugin is not
available, but could<br>
be installed. It is possible to give more hints on how to
install a plugin<br>
by setting the following option:<br>
<br>
.. option::
GDAL_DRIVER_<driver_name>_PLUGIN_INSTALLATION_MESSAGE:STRING<br>
<br>
.. option::
OGR_DRIVER_<driver_name>_PLUGIN_INSTALLATION_MESSAGE:STRING<br>
<br>
Custom message to give a hint to the user how to install a
missing plugin<br>
<br>
<br>
For example, if doing a build with::<br>
<br>
cmake ..
-DOGR_DRIVER_PARQUET_PLUGIN_INSTALLATION_MESSAGE="You may install
it with with 'conda install -c conda-forge libgdal-arrow-parquet'"<br>
<br>
and opening a Parquet file while the plugin is not installed
will display the<br>
following error::<br>
<br>
$ ogrinfo poly.parquet<br>
ERROR 4: `poly.parquet' not recognized as a supported file
format. It could have been recognized by driver Parquet, but
plugin ogr_Parquet.so is not available in your installation. You
may install it with with 'conda install -c conda-forge
libgdal-arrow-parquet'</p>
<p>I'll submit soon the RFC to vote if there are no further remarks.<br>
</p>
<p>Even<br>
</p>
<p></p>
<div class="moz-cite-prefix">Le 06/11/2023 à 14:50, Even Rouault via
gdal-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:876e96b5-b416-4d0e-a997-0ca65d619ece@spatialys.com">Hi,
<br>
<br>
I've revised a bit the RFC
(<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/8648/commits/b7053db2f433275edf16286596e71f3ceb9738a5">https://github.com/OSGeo/gdal/pull/8648/commits/b7053db2f433275edf16286596e71f3ceb9738a5</a>)
to unify the way the plugin driver proxy and the actual driver
declare their metadata. This avoids the new
GDALPluginDriverFeatures class, and will limit the risk of
omissions or inconsistencies between the proxy and actual drivers.
<br>
<br>
Even
<br>
<br>
Le 02/11/2023 à 12:59, Even Rouault via gdal-dev a écrit :
<br>
<blockquote type="cite">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 <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/8648">https://github.com/OSGeo/gdal/pull/8648</a>, 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>
<br>
Even
<br>
<br>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>