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
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.
Christopher Barker, Ph.D.
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
gdal-dev mailing list