text: 
  altern wrote:
  >?
  >
  There are patches in current CVS for building with FreeGLUT. They are
  also available in the patch tracker on SourceForge.
  HTH,
  Mike
  --
  ________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  Mark Heslep wrote:
  > I'm trying to gather the lessons-learned so far on the great ctypes -
  > PyOpengl work, especially with respect to the auto generated wrappers.
  > Id like to do the same w/ another large (larger) OS project (OpenCv).
  > So far I have:
  > -pulled the ctypes branch from CVS
  > -Read the ooffice doc in there
  > -Surfed for comments on M. Fletcher's vrplumber blog.
  > -Surfed through ctypes-users mail for codegen. comments.
  >
  > I'm hoping to get some pointers on the best way / lessons learned on
  > autogen'ing the wrappers. Agreed that ctypes is a better bet than SWIG
  > for all the reasons listed the doc above, but for a project with >10k
  > header lines Ive got to have the majority of the work autogen'd. So
  > some specific questions:
  >
  > -Is the consensus that the ctypes wrapper is workable for a production
  > release and if so is there some guesstimate of the road map/schedule to
  > do so?
  >
  If you mean the ctypes OpenGL wrapper, no, it's not ready for production
  work. This is mostly because it hasn't been ported properly to Win32 or
  OSX platforms, let alone the exotic older Unixes or DOS. There are also
  lots of extensions that would work with PyOpenGL that haven't had any
  attention paid to make them work naturally with OpenGL-ctypes.
  As for road-maps, I would *like* to get OpenGL-ctypes released very soon
  after Python 2.5 is released, but I can't make any sort of guarantees on
  that.
  > -The code generation module has been pulled from the pending Py 2.5
  > inclusion of ctypes. Looks like M. Fletcher suggested this. Is this a
  > problem, indicating no faith in the codegen?
  >
  No. The issue is that the code generator is still very early in its
  life-cycle and is subject to rapid and incompatible changes. Thomas is
  actively working on it, and as such *extending* or customising it is
  dangerous (i.e. will likely break in the future). IIUC Thomas is
  returning it to the code base for the next release.
  > -Which version of ctypes is to be used for PyGl?
  >
  OpenGL-ctypes is targeting ctypes 1.0.0 release and Python 2.5 bundled
  versions. I'm also trying to keep computability with the recent 0.9.9.x
  releases where practical to make development/testing easier.
  > -Are there some summary docs (even code comments) that explains the
  > method / approach to making the wrappers? The docs above do a good job
  > of explaining why, but I've not found a how.
  >
  I ran the auto-generator to produce the "simple.py" modules. I created
  an __init__.py that imported the results of those into the right
  namespace, then I started testing. First thing I ran into were the
  pointer/array problems, so modified the code generator to hack that in.
  If something was easier to code without the auto-generation, I would
  create a module that shadowed the auto-generated symbols and import that
  into the namespace on top of the "simple" module. Lather, rinse, repeat.
  Once the basic array-handling was in place (and particularly the
  "wrapper" module abstractions) the amount of work for any given function
  fell off rapidly (or entirely disappeared). Compound structures, error
  handling and the like were involved as well, but mostly because I wanted
  them to act like the original system (PyOpenGL).
  Sorry for the delay on replying to this,
  Mike
  --
  ________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder?
  many thanks
  -
  enrike