[Gdal-dev] Converting an exiting OGR loader into an "optional"
loader?
John Johnson
jdjohnso at google.com
Mon Sep 11 21:39:43 EDT 2006
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.gOracle 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.
So my goal is to build a single version of GDAL configured with several
"optional" 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.
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.
I figure that other existing loaders that could benefit from this
"optional" 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.
My issue now figuring out the best way to convert these existing loaders (
e.g. Oracle Spatial's OCI) to support this "optional" 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 "optional" module instead of default behavior
of linking it directly into the GDAL library.
I realize that this is signifcant enough of a change that I'd need buyoff
from the "powers that be" before a patch would ever be accepted back into
the mainline build. So I'm asking now. Does this seem like a reasonable
approach?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20060911/68ee17ea/attachment.html
More information about the Gdal-dev
mailing list