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

[Jason Roberts]

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?

 

Yes, it would mean that. One build for Python 2.5, one for 2.6, one for 2.7,
etc. This is how it is typically done.

 

 

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.



I was not saying that setup.py be forked and a special copy exist for
windows. I was saying that setup.py should internally check whether it was
being executed on Windows (check Python's sys.platform variable), and then
perform special logic. But this may be moot because it sounded like Frank
was not keen on my suggestion of enclosing a private copy of the GDAL DLLs
with the Python bindings. If we avoid my suggestion then we are left with
the idea of putting them in \Program Files\GDAL. In that case, we would not
need to modify setup.py for this purpose. 


 

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

I do not think it would be good to tamper with setting the PATH. I am not
certain, but I think Python's environment handler may call _putenv rather
than SetEnvironmentVariable, or something like that, which can cause some
problems. It might be better just to use SetDllDirectory. Also, as Chris
pointed out, the Python ctypes module can be used to call win32 APIs. This
would eliminate the need for a new _gdal_dll_loader module. Instead, the
try/except block that I described below would just call win32 directly via
ctypes. It could do the necessary SetDllDirectory/LoadLibrary/etc itself.

 

 

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.

 

Sounds good to me.


 

 

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)

If we follow the \Program Files\GDAL suggestion, then I further suggest that
GDAL itself be modified to use that location as the default for GDAL_DATA,
GDAL_PLUGINS, etc. That way the user does not have to set ANY environment
variables for GDAL to work. That would be a major plus because, frankly,
Windows users rarely have to set environment variables.





Best regards,

Tamas

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