[gdal-dev] Problem with GDAL Python bindings and ECW format under Windows

[Jason Roberts]

I didn't think we were discussing platform-independent solution for linking bindings with the GDAL libs, as different operating systems have radically different installation locations. The existing platform-independent way to do it is to put GDAL's binary directory in the PATH. That is what I thought we were trying to get away from on Windows, in an attempt to solve DLL hell and the "just works" requirement at the same time. If we eliminate environment variables from the candidate solutions, the only other two that have been discussed in any detail are using the registry (Tamas's suggestion) and what I called "documenting the appropriate logic". That latter approach might also be called "checking in a well known location" or something like that.

Anyway, this is why we need an RFC, as Frank requested. I still intend to write one when I can get free from my day job responsibilities, assuming someone else doesn't write one first...

Jason

-----Original Message-----
From: gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Christopher Barker
Sent: Tuesday, January 25, 2011 6:50 PM
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows

On 1/25/11 2:57 PM, Jason Roberts wrote:
> Rather than introduce a DLL into the system directory, why not
> statically link the code into the bindings themselves, when possible?

we did go through that, and it's one option, but for those of us that 
use gdal with C programs, python, with the utilities, all -- it's nice 
to know that you're using the exact same version for everything.

> document the appropriate logic for doing it with win32 functions
> (registry functions, LoadLibrary, GetProcAddress) and allow the bindings
> to make those calls themselves? Most languages have a way to access
> win32 functions.

yeah, but ugly and platform dependent. (of course, I just have a 
distaste for the registry)

I thought we had more or less come up with a consensus that the language 
bindings (Python, anyway) would take care of finding gdal and setting up 
the environment, and that we would facility things "just working" by 
using standard install locations.

This would let casual users have a simple "run the installers and it 
works" experience, but more sophisticated users could easily customize 
their systems, have multiple versions installed, etc.

And no installers would set anything up system wide.

(though I have no problem with a "check this if you want the Environment 
set up" box in the gdal installer)



> It just seems unnecessarily risky and complicated to
> create a new DLL and put it in the system directory, IMHO.

agreed.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev