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

[Jason Roberts]

Frank,

Thanks for the clarification of the various issues. I will start an RFC for
this next week.

Jason

-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Friday, January 07, 2011 10:29 AM
To: Jason Roberts
Cc: gdal-dev at lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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