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

[Tamas Szekeres]

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


>
> So #3 is not better by virtue of not having to modify the bindings; it does
> have to modify the bindings. But #3 is appealing because setting the PATH
> from Python code sometimes has weird issues. For example, when I tried it in
> my code, it produced a weird problem when I tried to use the “nose” Python
> testing framework to run test cases that involved calling Python modules
> from GDAL and ArcGIS. The problem there may ultimately be a Microsoft issue
> in which the environment settings for a process are maintained by the
> Microsoft C runtime library (msvcrt*.dll) and Python, ArcGIS, and GDAL may
> use different versions of that library. I do not want to digress into this
> here, but suffice to say, I prefer #3 to #2 because it did not have this
> problem.
>
>
>

This is quite a common issue the getenv/_putenv CRT functions operate only
on the data structures accessible to the run-time library (CRT) and not on
the environment "segment" created for the process by the operating system.
In this regard the libraries work only on a snapshot of the variables that
have been set during the CRT startup. In this case we should probably find a
function that invokes the
SetEnvironmentVariable<http://msdn.microsoft.com/en-us/library/ms686206%28v=vs.85%29.aspx>API
instead.



>
>
> 1.    Modify the makefiles for your SDK so that it runs
> release-XXXX-dev\gdal\swig\python\setup.py with the “bdist
> --formats=wininst” option. This will produce an installation program such as
> gdal-1.7.3.win32-py2.5.exe. This is what the user will run to install the
> Python bindings together with a private copy of the GDAL DLLs used just by
> those bindings. On Python 2.6 and later, we probably want “bdist
> --formats=msi” to produce a .msi file rather than a .exe, because Windows
> likes .msi files much better than .exes for security purposes. IIRC, Python
> 2.5 and earlier do not have the msi option.
>
>
>
This can be done fairly easily. Does this mean we would require each build
for multiple python versions?


> 2.    Modify release-XXXX-dev\gdal\swig\python\setup.py to include the
> GDAL DLLs and data files in the data_files list that is passed to the
> setup() function. Make sure it is only done for Windows (Python code can
> check that). The goal is to have the installation program create the
> following kind of installation:
>
>
>
Hmmm. I'm keen to avoid any local modifications in the compiled files
throughout the build system. Do we have some option to load this infromation
from an external file (which is probably loaded by setup.py if exists)? Or I
must write a custom setup2.py containing this customization.



> 3.    Introduce a new file
> release-XXXX-dev\gdal\swig\python\extensions\_gdal_dll_loader.cpp. This file
> will call GetDllDirectory to find the current DLL directory setting, call
> SetDllDirectory to C:\PythonXX\Lib\site-packages\osgeo\bin (or wherever the
> Python instance is installed), call LoadLibrary("gdal17.dll"), and call
> SetDllDirectory back to what it was before. There are more details to
> consider. For example, we might want to have it call LoadLibrary first to
> see if it can load the GDAL DLL from the PATH, allowing the user to use
> their own GDAL DLLs without having to overwrite the ones in the Python
> directory. Or we might *not* want to do that, with the idea that the GDAL
> Python bindings must be tightly coupled to a particular version of GDAL’s
> DLLs.
>
>
>
That seems to be quite complicated, not sure it that's working for those
libraries using LoadLibrary binding at run time. Wouldn't that be better
getting back to add the location to the PATH of the process in a loader.py
(using SetEnvironmentVariable).


> 5.    Modify gdal.py, osr.py, and so on to do something like this:
>
>
>
> import sys
>
> if sys.platform == 'win32':     # TODO: add check for Windows x64 as well
>
>     try:
>
>         import osgeo._gdal_dll_loader          # As part of this, Python
> will call an “init” function inside. That function will do the
> SetDllDirectory, etc.
>
>     except:
>
>         pass
>
>
Such changes can be done in the SWIG interface files easily.


>
>
> 6.    Do whatever is necessary to ensure the GDAL_DATA etc are properly
> set up inside GDAL. I can’t remember if this will “just work” using
> directories named gdal-data, gdal-plugins, or if it is necessary for the
> _gdal_dll_loader.pyd to call some GDAL functions to make it happen.
>
>
>

I guess this could also be set form a python script (probably from
loader.py)


Best regards,

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