Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Tamas Szekeres]

2011/1/6 Jason Roberts <jason.roberts at duke.edu>

> 2.    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.
>
>
>
> 3.    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 SetDllDirectory<http://msdn.microsoft.com/en-us/library/ms686203%28v=vs.85%29.aspx>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.
> 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.
>
>
>
>
Jason,

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.

#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)

#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)


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.


Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110106/ba816310/attachment.html