PDAL had this penalty and then we did some profiling and saw that most of the cost was the dlopen, not the
finding of the plugin via the filesystem. PDAL doesn't have a GDALOpen-like single entry method where drivers
are all expected to be loaded and "tried" sequentially, however. We have a map that registers some
properties of the "filename" that tells us which driver to actually dlopen, which is managed by
libpdal.so. Users also have the ability to explicitly say "open this file with this driver at this
dll/so location", which allows them to short cut the map.
yes my profiling also shows that it is essentially due to the dlopen() time.
Loading only the plugin you need, in an automated way, is not currently
possible, because the Identify() method is in plugins. For simple
identification by file extensions, we could imagine having some registry
mapping extension(s) to plugin name, but the Identify() method can do
much more complicated stuff
- offering the possibility of building just a driver as a plugin in a unit way
would require people to build against the same GDAL headers as libgdal.
Does it really? If communication across the boundary of the plugin to GDAL is
using public GDAL pointers/classes/methods that haven't changed in many
releases, does the plugin version actually need to perfectly match the main
library version?
Possibly 2 issues:
- you need to build a driver against the headers of the library you are
going to run it against: even if the API remains compatible, you still
need to build your plugins against GDAL headers of the same major.minor
version due to ABI changes that occur almost at every feature release
due to new virtual members or other such ABI incompatible change.
- you could possibly build driver FOO from GDAL 3.X sources against
headers of GDAL 3.Y, but that may not be possible for all X,Y
combinations due to some utility methods being added / changed /
removed. For example in GDAL 3.6 we have remove the _GetProjectionRef()
compatibility layer of GDAL 3.0. So if you build driver FOO from GDAL <
3.6 against GDAL 3.6 headers, that isn't going to work (and probably the
reverse)
For PDAL it hasn't, and we have used older binary plugins against newer main
libraries with success. PDAL's interface in this regard is smaller, however, so
the risk of changes causing problems are less. You could also wire in some
explicit plugin versioning if you wanted a way to force a bump. I think if this
were a community desire and priority, it could be done.
The ABI that plugins directly or indirectly depend on is quite large. I
don't see how we could have a stable ABI, at least not without
significant complication and bloat.
Requiring when building a standalone plugin that you use the same X.Y
GDAL version for the plugin source and the GDAL headers doesn't seem a
unreasonable requirement to me.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
