<br><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;">
<div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);">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.</span></p>
<p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div><br>Jason,<br><br>I've already used WIX many times and I'm very satisfied with it.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);">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.</span></p>
<p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);"> </span></p><p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);">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.</span></p>
<p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);"></span></p></div></div></blockquote><div><br>Just by thinking about the details if we implement a smart dll loader which could in fact work with any locations to load the dll-s why do we require to use a specific folder as the install location? The installer may create a registry entry or a config file in a specific place where the necessary dependencies are installed actually. The loader would be responsible to query for a compatible entry and use that location when loading the dependent dll-s. If no entries found the loader would provide an error that a dependent setup should also be executed.<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;"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);">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.</span></p>
<p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div><br>It would not be a problem in the scope of my comments above. The user could install multiple versions anywhere and the loader would be responsible to find out the corresponding version at run time. <br>
<span style="font-size: 10pt; color: rgb(31, 73, 125);"> <br></span></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US">
<div><p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);">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.</span></p>
<p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);"> </span></p><p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);">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.</span></p>
<p class="MsoNormal"><span style="font-size: 10pt; color: rgb(31, 73, 125);"></span></p></div></div></blockquote><div><br>We could probably implement the loader in C an use SWIG to map the functions to the various languages. The implementation would be the same for all languages in this regard.<br>
The only issue here is that where to place the loader.dll (providing the core implementation) which would also rely on the Windows dll search rules. For python you could easily say to create a pyd installed along with the python files, but in may not be so trivial for the other languages. I'm tending to think that this part should probably be implemented in a generic way (which doesn't change frequently) and be installed in a common folder available in the PATH.<br>
<br>Best regards,<br><br>Tamas <br></div></div><br><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>