Opened 16 years ago

Closed 15 years ago

#2578 closed defect (fixed)

SWIG Python Build Broken on Windows

Reported by: warmerdam Owned by: dron
Priority: high Milestone:
Component: PythonBindings Version: svn-trunk
Severity: major Keywords:
Cc: hobu

Description

I am unable to buid swig python bindings on windows now due to dramatic changes in setup.cfg and setup.py in r15378, r15379, and r15385. These do not appear to address the non-unix situation where we do not have a working gdal-config script (for MSVC builds).

It appears these dramatic changes were made without consulting hobu - should they have been?

If there isn't a resolution shortly, I'll backout the above revisions.

Change History (6)

comment:1 by dron, 16 years ago

Status: newassigned

Frank,

What is a problem exactly? I can't test it immediately because I don't have a MSVS 2003 and distutils refuse to build with my MSVS 2005. I will install 2003 and try to reproduce the problem.

These changes were done in order to support the MinGW compiler and now it can be used in any way: cross-compilation in Linux, native compilation in Windows, native compilation in Wine environment.

comment:2 by warmerdam, 16 years ago

Andrey,

The behavior I see is that supporting libraries (GEOS, etc) are not getting linked in. But the setup.cfg file seems to depend on calling gdal-config which does not work (or at least appears not to exist) in my build tree.

comment:3 by dron, 16 years ago

Finally I managed to install MSVC 2003 and reproduce this problem. It should be fixed with r15442. Please, test it.

comment:4 by hobu, 16 years ago

Andrey,

This is not a satisfactory solution. The reason why I moved to using setup.cfg instead of embedding the includes/libraries in setup.py are as follows:

  • This is the standard Python way to do it.
  • It allows us to use PyPI to distribute the Python bindings *without* having to have the built in the source tree.
  • It helps to eliminate the need to go trolling through setup.py to edit include locations.
  • People can replace their own setup.cfg in packaging environments.

What was it about the setup.cfg solution that didn't work for Mingw/cygwin exactly? Could you not edit include/library locations in it to get it to work?

Sorry to dig in my heels on this, but I put a lot of work into setup.py so we could get to the point where we could build the GDAL bindings *outside* the GDAL source tree. This was important for PyPI inclusion as well as it streamlined stuff for the packaging folks. I don't want to go back to where we were. What edits would have to be made to setup.cfg to make mingw/cygwin work, and once we find them, we should leave them commented out as a block (to start with, anyway) like we do with the msvc variables there.

comment:5 by dron, 16 years ago

Ok, that is reasonable. I have tried to satisfy the requirements with r15445. Tested on Linux, MinGW (wine), MSVC 2003. Now the one can override hardcoded defaults using setup.cfg.

My main goal is to have out-of-box compilable bindings without any additional configuration. So there are default parameters. The problem with MinGW (and maybe Cygwin, but I haven't tried that) is that directories in the lists should be separated using os.pathsep delimiter, which is ':' on Linux and ';' for Windows. That is what distutils will use when parsing these options in setup.cfg. I would like to have some unified configuration options and don't touch them every time I need to use some other building environment.

comment:6 by dron, 15 years ago

Resolution: fixed
Status: assignedclosed

Because of no further objections I am considering this one fixed.

Note: See TracTickets for help on using tickets.