[gdal-dev] Improving details of the project build system and/or documentation

[Even Rouault]

> 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.