• 2005
  • September
  • 23
  • Convenience during development (Forgotten during release...)

Convenience during development (Forgotten during release...)
Written by on in Snaking.


So it appears that the recent spate of failures to build PyOpenGL are all basically the same problem. As I was developing PyOpenGL 2.0.2 I removed a check that was looking for an explicit version of SWIG (1.3.13), as I was moving to SWIG 1.3.23. I didn't spend the 10 seconds or so it would have taken to update the test, I just killed the whole test, thinking that I might wind up using 1.3.24 or even 1.3.22 eventually.

Oops.

The problem is that the default PyOpenGL build command attempts to rebuild the wrapper modules... which, with the wrong SWIG installed (and many distributions now install SWIG), will corrupt the wrappers iretrievably and result in weird compilation errors during the build_ext command.

Sorry about all the wasted time people.

Comments

  1. Texas Fuzz

    Texas Fuzz on 09/24/2005 1:41 a.m. #


    FYI, wrapping a large and very complicated C++ library for access from Python, I've found that SWIG 1.3.22 provides the best balance of features and reasonably efficient code generation of any version 1.3.18-25.<br />
    <br />
    1.3.23-24 are more buggy than 1.3.22, and 1.3.23-25 all generate much more bulky code (yielding larger binaries that're moderately slower). 1.3.18-21 are just too buggy to seriously consider.<br />
    <br />
    The situation might be different for C/Python than for C++/Python; I don't know.

  2. Mike Fletcher

    Mike Fletcher on 09/25/2005 8:18 p.m. #


    Thanks for the info, not likely to switch versions just now. We basically don't use *any* feature of SWIG past that in the (now ancient) version of SWIG Tarn used to wrap the libraries, so almost any version winds up being stable for us. Heck, if I didn't get so many complaints about the old version I'd never have bothered updating at all.

Comments are closed.

Pingbacks

Pingbacks are closed.