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

[Jason Roberts]

Chris,

Here are some comments on specific parts of your mail:

> me neither, with Python (or anything Windows, for that matter). Maybe 
> Jason knows better, but I *think* we should be OK with a standard 
> location for GDAL. But could you have:
>
> Program Files\GDAL\1.6\gdal.dll
>   and
> Program Files\GDAL\1.6\gdal.dll
>
> and have one Python binding find 1.6, and one find 1.7 -- I'm not sure 
> how to do that, but it SHOULD be doable! OH what i'd give for a symlink!

Those would be reasonable locations for GDAL to live if the GDAL team
decided to distribute the GDAL binaries using an installer that adhered to
the best practices on Windows. But putting them there would not mean they
would be automatically added to the PATH. The GDAL Python bindings would
still have to use one of the options I mentioned to load the binaries there
(e.g. modify the PATH).

Incidentally, Windows does support both symbolic and hard links, although it
is not widely known, and I'm not sure I'd recommend their use for this
particular problem.

> I think 2.5 is MSVC2003 (but that may be 2.4, my memory is fading...).

I believe both 2.4 and 2.5 used MSVC2003.

> Great summary -- thanks! And you clearly have a better grasp that I on 
> Windows dll hell.

I used to work for Microsoft, back in the day... :-)

>> Modify gdal.py to set
>> os.environ['PATH'] = os.environ['PATH'] + ';' gdalInstallDir to modify
>> the PATH to include that directory prior to importing _gdal.pyd. The
>> PATH will be modified for the running process only, for the duration of
>> that process.
>
> I didn't think that was required, if the dll is in the same place as the 
> *.pyd, but maybe it is. And it seems it would work fine. Might it mess 
> things up if someone where to do a system call from Python? Also, would 
> that support py2exe?

Unfortunately, it is not sufficient to simply put the GDAL DLLs in the same
directory as the GDAL .pyd files. When the .pyd tries to load the GDAL DLL
through "implicit" linking, Windows checks the locations described in
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx.

You are probably thinking of the first rule in that list, "the directory
where the executable module for the current process is located", i.e. the
.exe file. In most cases, this is C:\PythonXY\python.exe. C:\PythonXY is
probably not an appropriate location for the GDAL DLLs. Plus it would not
work for other executables that host the Python interpreter, such as
C:\Program Files\ArcGIS\Bin\ArcMap.exe.

Incidentally, the Python interpreter itself is in a DLL that Python installs
in C:\Windows\system32, which is always very high up in the PATH. GDAL could
put its binaries there. But that might be very risky because GDAL ships a
lot of DLLs that other apps might also use. For example, GDAL optionally
includes xerces-c, which MATLAB and ArcGIS also use, among others. Plunking
GDAL's own copy of xerces-c into the PATH will screw up those apps.

> I wonder what is donefor theones here:
>
> http://www.lfd.uci.edu/~gohlke/pythonlibs/

I have been meaning to look at that since you originally sent it. It
probably gives an example of the kinds of stuff I mentioned. I wonder if it
is statically linked. Rgdal is one example where someone has statically
linked GDAL into their own project.

> could all that be done with some ctypes calls, rather than another 
> extension?

Yes I believe you are absolutely right. I always forget about ctypes because
I'm working on something that must be compatible back to Python 2.4 and
ctypes was not included in 2.4.

Jason