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, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
