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-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Christopher
Barker Sent: Tuesday, January 25, 2011 6:50 PM To:
gdal-dev@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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
