Bugzilla Bug 133602

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.