[Gdal-dev] Incorrect plugin search when registering GDAL drivers

[Frank Warmerdam]

On Wed, 19 Jan 2005 19:46:02 +0100, Marek Brudka <mbrudka at aster.pl> wrote:
> I agree, this is less convenient that using GDAL_DRIVER_PATH path. But
> it is simplier
> and more explicit design. Simplicity of the interface is the one of the
> most desired feature for
> any library. This is why OGC standards are so cool :-)

Folks,

Marek and I discussed things a bit in IRC but I thought I should summarize
and answer a few questions here. 

First I congratulated Marek on his joke about OGC standards, but 
apparently he meant it seriously.  I guess they are simple and clean
compared ... to some other standards.

> In general, one after installing gdal-devel libraries should not set
> anything in environment, because
> (Morphy Law) for sure he or she will not do this.

The CPLSetConfigOption() concept is intended to allow GDAL applications
to control things without environment variables while given end users an
opportunity to influence how GDAL based software operates after the fact.
But environment variables are not required.  I would add that the
--config option
to many GDAL programs can be used to set config options.

> Sure. But this means, that almost any application should call
> CPLSetConfigOption() before
> registration of GDAL drivers.


> If you decide to load plugins from a default path, when GDAL_DRIVER_PATH
> is undefined
> I propose to not search in /usr/local/lib, but /usr/local/plugins/gdal/,
> /usr/local/lib/plugins/gdal or something similiar.
> Please notice, that plugins aware applications usually has their own
> specific search path eg. mozilla, opera, qt .., and
> do not even try to look into system wide directories.

I have changed the default path to be /usr/local/lib/gdalplugins in CVS.
I have also modified the autoloader to check that the target files have
the .so, .dll or .dylib extension. 

As discussed elsewhere I have also committed support for OGR plugins
(name stuff like ogr_<drivername>.so) though I have not yet tested it.  
 

> I ACE there is a convention for library names. Debug library under
> windows is called <name>d.lib, <name>d.dll,
> while for unix lib<name>d.a and lib<name>d.so. Release versions does not
> have 'd'. When compiling any project a
> macro is defined (or DEBUG NDEBUG standard macros are used) to tell if
> this is Debug or Release version. That's
> enough to discriminate between plugins. I agree, that this solution is
> not the ideal one, but manages almost all
> practical situations.

Well, I'll keep this in mind, but I haven't really supported overlapping debug
and release versions of stuff in GDAL generally (to the annoyance of at least
a few users). 

> The solution you proposed is more elaborated, and I think it is better
> than the above, because really attacks
> the problem.

It addresses version differences but no build option differences.
 
> >I considered doing this; however, it would often then consider
> >plugins incompatible that would have worked if they were compiled
> >for a slightly different but ABI compatible version.  The central issue
> >here is that the GDAL C++ ABI changes frequently but not with every
> >minor version.  It is really only the  C ABI that I try to maintain strict
> >backward compatibility for.
> >
> >
> I suppose that compatibility level can be controlled when loading
> plugins eg.
> we can assume that version string contains detailed information on GDAL
> major and minor
> versions as well as build variant. W plugin can be considered to be
> compatible when major
> version and build variant agree.

But as it turns out GDAL is C++ ABI incompatible between many 
minor revs as well. 
 
The more I consider wide deployment, the more I think I should
just do exact versions comparisons.  I won't act on this yet though.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent