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

Fri Jan 7 10:07:57 EST 2011

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.

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.

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.

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.
Therefore the bindings must be changed to look for the GDAL libraries in the
well-known location. Because they currently use implicit linking, they are
tightly coupled to a particular version of the libraries. The user will have
to be aware that they must install a compatible pair of bindings + GDAL. The
GDAL team should decide right now about the X.Y vs. X.Y.Z compatibility
question.

Regarding x86 vs. x64. The GDAL installer should follow the standard
Microsoft convention. On an x64 machine, the x64 GDAL utils/libs should go
in \Program Files and the x86 utils/libs should go in \Program Files (x86).
The bindings and other integrators must be aware of x86 vs. x64 and locate
libs from the correct directory.

I agree that calling SHGetSpecialFolderLocation with an appropriate CSIDL is
an appropriate way to find the Program Files directory (addressing issue
noted by Joaquim and others that Program Files is localized). It is probably
ok to use the ProgramFiles and ProgramFiles(x86) environment variables if
calling the Win32 API is not easy for particular bindings.

Jason

From: Tamas Szekeres [mailto:szekerest at gmail.com] 
Sent: Friday, January 07, 2011 5:26 AM
To: Jason Roberts
Cc: Frank Warmerdam; gdal-dev at lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

2011/1/7 Jason Roberts <jason.roberts at duke.edu>

Thanks for your thoughts. Based on them, I'd recommend the following two
things be created.

1. GDAL windows installation program, or at minimum, a wiki page that says
how to install the GDAL libraries and utilities (executables and Python
scripts) to \Program Files\GDAL\... Perhaps a quick compromise would be for
Tamas's build system to produce a .zip that would have everything in a
suitable directory structure and for wiki page to instruct the user "just
unzip this to \Program Files\GDAL\...".

Jason,

What would be the suitable directory structure? I'm keen to provide an
installer which could place the files to the right location. By using WIX
<http://wix.sourceforge.net/>  it's could be generated automatically by the
command line tools candle.exe and light.exe during the build process easily.

However naming the install root folder to GDAL doesn't seem to be a right
thing as we provide other packages like mapserver as well. For the sake of
simplicitly I could imagine to place everything in a common folder (like
SDKBuilds) and add a shortcut for invoking a command prompt (for starting
the commandline tools) and a shortcut to uninstall the package. I would also
mention OSGeo as the root, but I'm not sure how it will violate the files if
a similar installer will ever derived from an OSGeo4W bundle. (We may
probably warn the user not to install both versions side by side)

I may also be mention that by default referring to the programsfolder in the
installation process may select different folders depending on the
architecture (Win32/Win64) or the OS version. I don't think it would be a
good way to force everything to be in  "C:\Program Files" which contains the
x64 binaries on x64 platforms for example or it may reside in various
logical drives on a particular system. It would probably be reasonable to
use something like SHGetSpecialFolderLocation
<http://msdn.microsoft.com/en-us/library/bb762203%28v=vs.85%29.aspx>  to
retrieve the current location in the loader program. 

2. GDAL Python bindings installation program. This could be easily created
using the standard Python distutils stuff I've been mentioning, and would
install the bindings to the normal Python place. The bindings would ideally
be modified to check for and explicitly load libraries from \Program
Files\GDAL\... This would eliminate the need to modify the PATH variable.

That's ok with me as a separate installer provided by distutils.

Best regards,

Tamas

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