Re: [PyOpenGL-Users] [PyOpenGL-Devel] Ctype autogen summary?

[Mike C. F. <mcf...@vr...>]

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
  http://www.vrplumber.com
  http://blog.vrplumber.com