On 06-01-2011 21:42, Christopher Barker wrote:
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
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.
I *think* we're heading for a consensus to do that, but not many
people have been on this thread.
Hi,
I have been following this with attention and sometimes I thought I had
something to say but than it has many python specific issues, which I'm
not versed at all. My experience with other installers is GMT & Mirone.
Here I simply put the gdal dll and ALL its dependencies (determined by
careful Dependency Walker analysis) in the same directory as the other
exes. Since this must be in the PATH, the gdal package goes along. But
this solution normally doesn't care about the gdal exes.
Also a word about the "best practice on Windows". I really don't see
anything not even good in that practice to put them in "Program Files".
Having directories with blanks in their name give nothing but future
problems when running command line programs (I have seen that happen
many times). The GMT & Mirone installs propose as default a C:\programs
diectory. Let me remember that "Program Files" is not a unique name. For
example in Portugues Win versions it is called "O Meus Programas"
(Horror). Remember also that MS used to have "Documents and Settings"
but now on Win7 it's only "Users".
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've heard that, but never seen it done.
It works pretty well, the command is mklink and works much like on *nix
BUT exists only on Vista and Win7.
Time to time, it has been raised also the hypothesis to put the dlls in
windowes\system32. PLEASE, PLEASE don't even think on that. It's the
easiest way of making the worst dll-hell. I learned that after spending
many hours trying to understand why GDAL was not working in the
classroom computers. It turned out to be an very old zlib1.dll put there
by ArcS*
Joaquim
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
