<br><br><div class="gmail_quote">2011/1/6 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><span style="font-size: 10pt; color: rgb(31, 73, 125);"><span>2.<span style="font: 7pt "Times New Roman";"> </span></span></span><span style="font-size: 10pt; color: rgb(31, 73, 125);">Build an installation package as above. Have it install the GDAL DLLs as a subdirectory of the osgeo directory, e.g. C:\PythonXY\Lib\site-packages\osgeo\bin. Modify gdal.py to set os.environ['PATH'] = os.environ['PATH'] + ';' gdalInstallDir to modify the PATH to include that directory prior to importing _gdal.pyd. The PATH will be modified for the running process only, for the duration of that process.</span></p>
<p><span style="font-size: 10pt; color: rgb(31, 73, 125);"> </span></p><p><span style="font-size: 10pt; color: rgb(31, 73, 125);"><span>3.<span style="font: 7pt "Times New Roman";"> </span></span></span><span style="font-size: 10pt; color: rgb(31, 73, 125);">Same as #2 but rather than modifying gdal.py to set the PATH variable, instead create a new Python extension module called _gdal_dll_helper.pyd. The job of this C extension module is simply to get gdal.dll and other DLLs loaded without resorting to modifying the system PATH which can sometimes have weird consequences (I can explain more if needed). The extension module would call the Windows <a href="http://msdn.microsoft.com/en-us/library/ms686203%28v=vs.85%29.aspx" target="_blank">SetDllDirectory</a> function, call LoadLibrary to explicitly load gdal17.dll into the current process, then call SetDllDirectory again to set the DLL directory back to what it was previously. Then, when gdal.py wants to load _gdal.pyd, gdal17.dll is already loaded and the binding succeeds.</span></p>
<span style="font-size: 10pt; color: rgb(31, 73, 125);">I know #2 and #3 sound scary but they can be done cleanly. I currently use a variation of #3 in my own project that embeds GDAL and its Python bindings.</span><p class="MsoNormal">
<span style="font-size: 10pt; color: rgb(31, 73, 125);"> </span></p><br></div></div></blockquote></div><br>Jason,<br><br>Good writeup, thanks for that. You mention #2 and #3 which is exactly the same I have in my mind. Already posted a code for #2 related to the csharp bindings to demonstrate this option.<br>
<br>#2 would be fairly transparent for the user (no additional modules imported), the only thing we could add is how gdal.py would find out the install location of the gdal files. This may probably set in the registry added by the installer. Not sure how this addition would affect the gdal binding on other platforms (if we implement this in gdal)<br>
<br>#3 seems to be better for gdal (doesn't require to modify the bindings) however the user will require to use an additional module (which is not required normally when using gdal.py)<br><br><br>I would personally vote on having an extension (like #3) which is imported by gdal.py in case if it is installed. If this extension is not installed, gdal.py would work as before. This extension would scan the registry to find out the install location of the corresponding files (probably based on an unique key) and perform the required actions to make the dll-s loadable.<br>
<br><br>Best regards,<br><br>Tamas<br><br><br><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>