Please see http://www.swig.org for reporting bugs and further information WARNING!!! wrong swig version. Need 1.3.13, continuing anyway. I had 1.3.25 installed.
The version check in that package is definitely braindead: it checks for an exact match on "1.3.13" in the output of swig -version. However if you do not have swig or have the wrong version of swig it should just use the prebuilt wrappers which should work fine (the ebuild does not depend on swig, and the package built successfully on my box with no swig installed and with ~x86 swig installed). Do you really need this "fixed" in some way? I could patch it to not try to find swig at all, but afaik there is no reason to do that other than avoiding this harmless warning?
Corresponding to http://pyopengl.sourceforge.net/documentation/installation.html pyopengl-2.0.2 should be installed with swig-1.2.23: PyOpenGL Version SWIG Version 2.0.1 SWIG 1.3.13 2.0.2 SWIG 1.3.23 Could pyopengl-2.0.2 included in the portage tree?
(In reply to comment #2) > Corresponding to > http://pyopengl.sourceforge.net/documentation/installation.html > pyopengl-2.0.2 should be installed with swig-1.2.23: > > PyOpenGL Version SWIG Version > 2.0.1 SWIG 1.3.13 > 2.0.2 SWIG 1.3.23 You forgot to paste this bit too (right above what you pasted): """If building from CVS (not a source archive, which includes the wrappers already), install the correct version of SWIG (see table below) and put the directory with swig.exe on your path where distutils can find it. Note that using the incorrect version of SWIG will not work, and will likely render your wrapper files unusable if you are using a source archive!""" As far as I understand there is custom c code in there that will fail in interesting ways if you rebuild the swig-generated source with a swig version that does not match *exactly* what upstream uses. I do not see what rebuilding the swig-generated c code would buy us here. Please correct me if I missed anything though. > > Could pyopengl-2.0.2 included in the portage tree? > I will look into that once we have figured out how swig should be handled here.
I hope you fix this soon. pyopengl 2.0.1's prebuilt bindings are incompatible with the Python 2.5 API and I've been waiting for a solution for two months now.
Ok, put pyopengl-3.0.0_beta1 in the tree. Since PyOpenGL-3.x uses ctypes instead of swig, this problem is fixed.
