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

[Chris Barker]

On 1/25/11 4:07 PM, Jason Roberts wrote:
> 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.

sure, but pure python that points to a path, it a lot easier than 
looking in the registry for something.
> 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.

I thought having python set the PATH at the beginning o of the import 
was idea -- that way it wouldn't mess up anything else.


> Anyway, this is why we need an RFC, as Frank requested.

yup

> I still
> intend to write one when I can get free from my day job
> responsibilities, assuming someone else doesn't write one first...

I'm waiting for you... ;-)

Thanks,

-Chris



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