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

[Joaquim Luis]

Jason,

I understand all that (though not necessarily agree). Possibly part of 
my reluctance stands also from the no-understanding of the degree of 
potential evilness attributed to PATH changes. Remember that path 
changes can be done on local profiles only or system wide but most of 
all, path changes are APPENDED to previous value of PATH not PREPEND (at 
least that's my experience with the Inno Setup) so it will not disrupt 
any other previously program that uses dll with same names. In the worst 
case what may happen is that that GDAL install would not work due to 
incompatibilities with previously installed libs. But that is essence of 
the dll-hell for which an universal solution is yet to come.

Joaquim

> Joaquim,
>
> I hear your pain about having the space in the name. It would probably 
> not be too much trouble for the installer to allow the user to change 
> the installation directory. That is a basic option of most installers 
> so it would probably not be hard to implement with a WIX-built installer.
>
> But I should reiterate that a requirement of this package is that the 
> GDAL bindings (installed as separate packages) must be able to locate 
> the GDAL libraries. The one approach mentioned so far is to put the 
> binaries in a well-known location. If the bindings were designed to 
> look for the libraries in a well-known location, they would be broken 
> if the user installed them to a different location. Therefore it is 
> important to pick a default location and recommend that only very 
> knowledgeable users select a different place. My view is that adhering 
> to Microsoft's best practice of using \Program Files outweighs the 
> convenience of using a directory off a root partition that does not 
> have a space in the name.
>
> An alternative idea is to store the location of the GDAL libraries in 
> the registry and then permitting them to be installed anywhere with no 
> consequences. The bindings would read the registry to determine their 
> location. This is also a fairly standard way to do things on Windows, 
> but it would be slightly more complicated for the bindings.
>
> Jason
>
> *From:*Joaquim Luis [mailto:jluis at ualg.pt]
> *Sent:* Friday, January 07, 2011 10:27 AM
> *To:* Jason Roberts
> *Cc:* 'Tamas Szekeres'; gdal-dev at lists.osgeo.org
> *Subject:* Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0
>
> On 07-01-2011 15:07, Jason Roberts wrote:
>
> Tamas,
>
> WIX looks like a great technology for building the installation 
> package. I've never used it but I took a quick look and it seems to 
> provide what is needed.
>
> As I understand it, you are pondering whether it would be better to 
> have GDAL in Program Files\OSGeo\GDAL or in Program Files\GDAL. Is it 
> simply a question aesthetics or principle, in which it seems proper to 
> put all OSgeo projects under Program Files\OSGeo, but there could be 
> problems coordinating the efforts of multiple projects to adhere to 
> that carefully and not mash each other's files? If that summarizes the 
> issue, then I'd recommend going with the more practical, less 
> principled approach: put GDAL in Program Files\GDAL, and OSGeo4W in 
> Program Files\OSGeo4W. It could get messy if both installers have to 
> be able to create the Program Files\OSGeo directory but not 
> necessarily delete it when they are uninstalled, because there could 
> be another OSGeo project in there.
>
>
> Let me just recall that OSGeo4W proposes the default install directory 
> as C:\OSGeo4W
> This is just my opinion and I feel quite at rest because I'm able to 
> build GDAL and install it wherever I wont, but I would really hate 
> that an installer would force me to install in a location contrary to 
> my will. In particular when that location has blanks in the name 
> (Program Files).
> But, as I said it's just my private view.
>
>
> Joaquim
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110107/3a8a07aa/attachment.html