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

[Frank Warmerdam]

On 11-01-07 10:07 AM, Jason Roberts wrote:
>put GDAL in Program Files\GDAL, and
> OSGeo4W in Program Files\OSGeo4W.

Jason,

I would note that OSGeo4W installs in C:\OSGeo4W by default, and there are
no plans currently to change this.  OSGeo4W will continue to use it's
internal copy of GDAL.

 > 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.

I would prefer to stick to C:\Program Files\GDAL.

> Along those lines, I would suggest that if GDAL plans to support side-by-side
> installations of GDAL itself, then we need to contemplate carefully whether to
> use Program Files\GDAL\GDAL-X.Y or Program Files\GDAL-X.Y. I think either one
> would be ok, so long as whoever writes the installer thinks out all the
> side-by-side installation/uninstallation scenarios.

I prefer to just use the major.minor version as the subdirectory name.

C:\Program Files\GDAL\1.7\

> Another question, also already raised, is whether to have just two or all three
> version numbers in the installation directory. I think that question depends on
> whether you ever need to support bugfix releases installed side-by-side (e.g.
> 1.8.0 and 1.8.1), and also whether the bindings and other integrators will need
> to bind to specific bugfix releases or not. For example, if you guarantee that
> all 1.8.x releases will have compatible ABIs—that you will never introduce a
> change that will break the binary interface without increasing the minor build
> number—then it would be ok to just use X.Y in the directory name. But if that
> cannot be guaranteed, then you need to support X.Y.Z so that bindings and other
> integrators can locate the specific bugfix release that they are compatible with.

It is an explicit guarantee that point releases do not change the C *or* C++
public ABI.  It is an explicit intention that a point release can be installed
over a previous release without impacting any applications using GDAL.  This
extends to the point that plugins should be compatible across point releases.

> Following up on that point: I think we’ve agreed that we do not want the user
> to have to set the PATH in order to have the GDAL bindings work.

I do *not* agree that installing GDAL would necessarily insert it into the
global PATH.  It might, or might not, but I'm still very concerned about
possible interference with other applications using GDAL.  I'm not saying
I will never agree to it, but I remain very cautious about interference
in the global space.  Particularly since we are likely to carry along lots
of other DLLs (zlib, xerces, etc).

If this installer is to be a product of the project, I would suggest you
write up a proposal as an RFC and we work from that.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent