Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Joaquim Luis]

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