[Gdal-dev] problem with new pyton-gdal

[Silke Reimer]

On Tue, Feb 10, 2004 at 11:49:00AM -0500, Frank Warmerdam wrote:
> 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.

OK. I will apply the changes to the cvs-version from 11.11.2003 and
release a new debian package (hopefully tomorrow). 

> 
> 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.

This sounds good. Thanks for your information. It gives me an idea
of the progress.


-- 
Silke Reimer

Intevation GmbH                      http://intevation.de/
FreeGIS                                http://freegis.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040210/f67b306d/attachment.bin