This document describes the process of
installing PyOpenGL 2.0.1 on
Win32 (Microsoft Windows) systems. Most users will only need to
download the pre-compiled binary packages and run the associated
installers (section 1), only those wishing to build from sources need
the detailed build instructions in the second section.
The packages you need to have installed for using PyOpenGL are as
Note: Numeric Python version 22 is incompatible with all versions prior to version 22, and if you use a version other than that used to compile PyOpenGL, you will get bugs and failures in your code! In particular, PyOpenGL 2.0.0.x releases were all compiled with Numeric Python 19 through 21 (all of which were compatible), as such, those releases will not work with Numeric Python v22, and the Numeric Python versions used for them will not work with PyOpenGL 2.0.1. Upshot is that you need to upgrade Numeric Python and PyOpenGL at the same time.
Once you have all of these dependencies installed, you can run the
.exe and it will install PyOpenGL to your site-packages directory.
Building PyOpenGL is, unfortunately, still somewhat involved on
Win32. There are a number of tricky system-configuration steps
that need to be done before you can build the package. (This
assumes you've already installed everything described above).
Once the system setup is done, building is the distutils standard:
setup.py build --force install
which will force a re-wrap, rebuild and install from your local
setup.py build_ext --force install
Will skip the wrapping stage if possible.
Note that currently we don't include the SWIG
wrappers in the CVS repository, so unless you got them from somewhere
else, the non-wrapping command won't work until the first command has
been run successfully. The wrappers are very large and change
constantly, and unless there is real need for them, we'd rather not
clutter up the CVS archive with them.
Note that you can force a single module to rebuild by "touch"-ing the .i file (in PyOpenGL2/interface) which defines the wrapper for that module. This is useful during development as it allows the first build-line above to go about wrapping and building the single extension with only minimal processing of the rest of the (large) package.