Add RFC96 text: Deferred C++ plugin loading

[rouault]

Partially rendered view here

[elpaso]

Is this change really necessary? Wouldn't be possible to delegate the loading to the pfn* in the proxy, maybe a generic function of the proxy that will load (once) the real driver and then call the real driver's pfn* ?

[rouault]

I acknowledge that this is not super pretty, but it is intended to be GDAL core low-level internal detail. The issue is for example that GDALDriver::Create() currently calls pfnCreate on the proxy driver, but it doesn't know that it is a proxy driver. When the proxy driver has not loaded yet the real driver, the pfnCreate callback is null... Hence this GetCreateCallback() virtual method implemented in the proxy driver that takes care of loading the real driver and setting the pfnCreate callback of the proxy with the value of the pfnCreate of the real driver. The alternative would be that each place that accesses the callbacks checks if the driver object derives from GDALPluginDriverProxy to force it to load the real driver, but I don't find that solution prettier.

[elpaso]

Looks good to me.
A big improvement.
I'd probably liked even more if the sidecar file solution would be implemented, but I guess that if that would work well with exposing metadata, for identify and subdataset it must necessarily be done in C++ code.

[tbonfort]

LGTM given that the scope is limited to deferred loading of in-tree drivers, but this has limited utility in the scope of rfc85 where we try to keep large/external/proprietary drivers out of tree

I'm wondering if it would be possible to obtain the same outcome with completely out-of-tree drivers, using some kind of code-generation at cmake time:

• cmake accepts -DADD_DEFERRED_PLUGIN_FOO=/path/to/foodriver/core.cpp with core.cpp containing the well-known functions FOODatasetIdentify, FOODriverSetCommonMetadata and DeclareDeferredFOOPlugin (in the same way that for traditional plugins we expect a gdal_foo.so file to contain a GDALRegister_foo() function)
• add the /path/to/foodriver/core.cpp to the list of files to be compiled into the main libgdal.so library
• use code generation to create the DeclareDeferredPlugins() function that will be called by GDALAllRegister():

// this file is automatically generated and will be overwritten, do not edit manually
void DeclareDeferredPlugins() {
  DeclareDeferredFOOPlugin(); //from -DADD_DEFERRED_PLUGIN_FOO
  DeclareDeferredBARPlugin(); //from -DADD_DEFERRED_PLUGIN_BAR
}

[rouault]

I'm wondering if it would be possible to obtain the same outcome with completely out-of-tree drivers

good point. Turns out to be quite straightforward. I've added a new commit in the RFC with that capability and candidate implementation in rouault@7f9c686

[rouault]

Candidate implementation available in #8695