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:szeker...@gmail.com] Sent: Friday, January 07, 2011 5:26 AM To: Jason Roberts Cc: Frank Warmerdam; gdal-dev@lists.osgeo.org Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0 2011/1/7 Jason Roberts <jason.robe...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev