[Gdal-dev] problem with new pyton-gdal

[Frank Warmerdam]

Silke Reimer wrote:
> Frank, is it possible, that the function  CPLFinderInit in
> port/cpl_findfile.cpp is responsible for  the searchpaths to finding
> the right file? In this case $prefix/share/gdal should be added to
> the FinderLocations or am I completely wrong? I don't know the code
> too well.

Silke (and Alessandro),

While cpl_findfile.cpp does have a hardcoded /usr/local/share/gdal, the
"real" place this is setup is the OGRSFDriverRegistrar constructor
which pushes an install location derived ultimately from the --prefix.
The GDALDriverManager constructor also does something similar.

The handling of this is based on the INST_DATA macro being defined at
compile time for the modules in question (ogrsfdriverregistrar.cpp and
gdaldrivermanager.cpp). Now that I do a quick test it seems that
INST_DATA is defined for gdaldrivermanager.cpp, but not for
ogrsfdriverregistrar.cpp.  That may be why OGR applications have trouble
finding their supporting files in some situations.   I have fixed this in
the gdal/ogr/ogrsf_frmts/generic/GNUmakefile.

I would add, for applications using GDAL, the data path can be set
with CPLSetConfigOption() to override built-in information.  When I used
to prepare my own Linux installable builds, I actually used the stuff
in gdal/dist_docs.  That install script would actually "burn in" a
location for the data files in the shared library at install time.

> BTW: Is there any plan to release gdal 1.2.0? I am not too glad with
> the CVS-version of gdal in debian. An official stable release would
> be much better.

I would like to have some comfort level that the libtool stuff is working
smoothly before proceeding with a 1.2.0 release.  Amoung other things I would
like to verify on a variety of platforms (I have some troubling reports from
UMN about Solaris builds), and to ensure that the configure scripts of some
major packages using GDAL will be ready for 1.2.0 naming conventions and
such (notably I GRASS and MapServer).

There are also a variety of outstanding bug reports that really should be
considered before a new "stable" release.

However, all that said, I still do hope to have a 1.2.0 release in the fairly
near future.

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