<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Verdana","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>Tamas,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>WIX looks like a great technology for building the installation package. I&#8217;ve never used it but I took a quick look and it seems to provide what is needed.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>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&#8217;s files? If that summarizes the issue, then I&#8217;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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>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&#8212;that you will never introduce a change that will break the binary interface without increasing the minor build number&#8212;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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>Following up on that point: I think we&#8217;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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>Jason<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Tamas Szekeres [mailto:szekerest@gmail.com] <br><b>Sent:</b> Friday, January 07, 2011 5:26 AM<br><b>To:</b> Jason Roberts<br><b>Cc:</b> Frank Warmerdam; gdal-dev@lists.osgeo.org<br><b>Subject:</b> Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0<o:p></o:p></span></p></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal>2011/1/7 Jason Roberts &lt;<a href="mailto:jason.roberts@duke.edu">jason.roberts@duke.edu</a>&gt;<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Thanks for your thoughts. Based on them, I'd recommend the following two<br>things be created.<br><br>1. GDAL windows installation program, or at minimum, a wiki page that says<br>how to install the GDAL libraries and utilities (executables and Python<br>scripts) to \Program Files\GDAL\... Perhaps a quick compromise would be for<br>Tamas's build system to produce a .zip that would have everything in a<br>suitable directory structure and for wiki page to instruct the user &quot;just<br>unzip this to \Program Files\GDAL\...&quot;.<o:p></o:p></p><div><p class=MsoNormal><br>Jason,<br><br>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 <a href="http://wix.sourceforge.net/">WIX</a> it's could be generated automatically by the command line tools candle.exe and light.exe during the build process easily.<br><br>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)<br><br>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&nbsp; &quot;C:\Program Files&quot; 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 <a href="http://msdn.microsoft.com/en-us/library/bb762203%28v=vs.85%29.aspx">SHGetSpecialFolderLocation</a> to retrieve the current location in the loader program. <br><br>&nbsp;<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal style='margin-bottom:12.0pt'>2. GDAL Python bindings installation program. This could be easily created<br>using the standard Python distutils stuff I've been mentioning, and would<br>install the bindings to the normal Python place. The bindings would ideally<br>be modified to check for and explicitly load libraries from \Program<br>Files\GDAL\... This would eliminate the need to modify the PATH variable.<o:p></o:p></p></blockquote><div><p class=MsoNormal><br>That's ok with me as a separate installer provided by distutils.<br><br>&nbsp;<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Best regards,<br><br>Tamas<o:p></o:p></p></div></div></body></html>