Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Tamas Szekeres]

2011/1/6 Christopher Barker <Chris.Barker at noaa.gov>

>
> On 1/5/11 3:12 PM, Tamas Szekeres wrote:
>
>> As far as I remember setting up the
>> following environment variables properly (in a command prompt) does the
>> right thing from arbitrary locations (at least when running the autotest
>> suite for GDAL):
>>
>> PROJ_LIB
>> GDAL_DRIVER_PATH
>> GDAL_DATA
>> PYTHONPATH
>> PATH
>>
>
> well -- first of all, setting environment variables on Windows is a PITA,
> second of all, is setting all that up easier than what Jason described?, and
> third, PYTHONPATH is a problem, particularly if you have more than one
> version of python installed.
>
>


Chris,

I did mention to set the environment for the cmd process solely, and not by
a systemwide setting. In this regard it doesn't matter how many python
runtime is installed on a particular system, the only issue is to refer to
the desired one (by setting the PATH to the python executable or using
absolute path when running python) from the command prompt.




> As I write this, I realize that maybe using or following OSGeo4w is the way
> to go -- put the gdal binaries wherever OSGeo4w puts them, and building the
> python bindings against that. Essentially letting OSGeo4w establish the
> standard.
>
>
The main issue I'm encountering with OSGeo4w is the problem supporting
multiple versions side by side which may trigger some problem for the
packages, for example:

1. If we would provide both x32 and x64 binaries how to ensure that each dll
or executable would load the corresponding version (by setting the PATH,
GDAL_DIVER_PATH in a different way whatever).
2. Most packages are from different sources so when compiling my package (ie
mapserver) I should rely on the dependent packages (like gdal) to compile
mapserver and then submit my package to the OSGeo4w repository. It wouldn't
be a best pactice to use my version of gdal at compile time, and let the
user rely on another version at run time. When upgrading gdal we should make
sure to upgrade the compilation of mapserver or provide having the older
version of gdal side by side which confuses the user.
3. Similar issue may exist with the multiple CRT dependencies privided by
the packages, for example when I would package my vesion of mapserver
compiled with MSVC2008 but we have only gdal-dev packages compiled with
MSVC2003 out there.


I wonder if there is some confusion about how the python bindings are used.
> You've referred to "setting up an application", making me think that you're
> talking about how to install an application, written in Python, that uses
> GDAL. IN that case I think you've got it right.
>
> However, what I'm thinking of is python developers, casual scripters. In
> this case you want to install python-gdal, and be able to fire up the
> interpreter and type "from osgeo import gdal" and away you go. For that use
> case, Jason has described the install process quite well.
>
>
Hmmm.. only for that reason fireing up the interpreter from a command prompt
(where PYTHONPATH has already been set) would probably work as well. But
indeed we may speak about different things, you may probably want to install
a single version of the gdal packages throughout the system, while I'd be
curious about the desired approach to host multiple versions side by side.


Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110106/9ab15a1a/attachment.html