The current build method for most loaders links them directly into the
GDAL library. This means that if those loaders need an external
library, GDAL will not load w/o that library being present on the
target machine. This means that if some of my users need a loader for a proprietary format (e.g Oracle Spatial), I either need to build two versions of GDAL (one with the OCI driver and one without) or I need to make sure that all of my users have the OCI client library installed. Neither option is very appealing to me.
<br><br>So my goal is to build a single version of GDAL configured with several &quot;optional&quot; loaders. That way if a customer has the necessary proprietary client libraries they will be able to use the optional loader. But if they do not have the necessary client libraries, the other loaders will at least still work.
<br><br>The current FMEObjects OGR loader already does this by using CPLGetSymbol to determine if the necessary FMEObjects client library is available. It does this during the Open so it can simply return FALSE if it can't load the shared library. It's a little bit heavy of an implementation (each Open call will try again to load the shared library), but it works.
<br><br>I figure that other existing&nbsp; loaders that could benefit from this &quot;optional&quot; loading functionality could be easily adapted from their current implementation by linking them into their own shared library (instead of into the main GDAL library) and by providing the additional RegisterOGRXXX function. The resulting shared libraries would be installed in one of the standard directories searched by the OGR Driver Registrar. If they are able to be successfully loaded at runtime (because the necessary external libs are present), they will be added to the list of drivers, otherwise they will be omitted.
<br><br>My issue now figuring out the best way to convert these existing loaders (e.g. Oracle Spatial's OCI) to support this &quot;optional&quot; loading of external libraries w/o breaking the build for everybody that expects them to behave the old way. I was thinking about a new configure option to specify that you want the library built as an &quot;optional&quot; module instead of default behavior of linking it directly into the GDAL library.
<br><br>I realize that this is signifcant enough of a change that I'd need buyoff from the &quot;powers that be&quot; before a patch would ever be accepted back into the mainline build. So I'm asking now. Does this seem like a reasonable approach? 
<br>