<br><div class="gmail_quote">2011/1/7 Jason Roberts <span dir="ltr"><<a href="mailto:jason.roberts@duke.edu">jason.roberts@duke.edu</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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 "just<br>
unzip this to \Program Files\GDAL\...".<br>
<br></blockquote><div><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 "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 <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> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
<br></blockquote><div><br>That's ok with me as a separate installer provided by distutils.<br><br> </div>Best regards,<br><br>Tamas<br><br></div><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>