Brian asked me to explain what benefits I'm expecting from a ctypes version of OpenGL versus the PyOpenGLSWIG version. So, why not post it where everyone can read it (if one person asks, probably 10 want to know)...
Easier compilation/more robust operation
o Probably 90% of our time in PyOpenGLSWIG is spent on
compilation issues
+ What few pieces of C code we'll need are going to be
simple and straightforward, easily debugged and then
forgotten, effectively we have a few pieces of code to
do those things that are either a serious pain in
ctypes or need C-level speed to be practical... and we
only decide which pieces those are with real-world
data saying "yes, that's the problem"
o We piggy-back on ctypes/libffi porting, let them deal with the
bulk of the cross-platform issues and the complex compilation
issues and we just need to be able to find the OpenGL DLLs and
pull entry points out of them.
Lower barrier to entry for users to hack on the system and become
developers
o Instead of an expanding macro system (SWIG) that matches via
unseen rules and can only be debugged by spelunking through
the final generated code, we get a system where you get a
traceback showing exactly what we were trying to do
+ Extension modules will just import the services they
need and use them, they won't have macro
comments that interact with a funky-hacked distutils
script to decide which versions to build
o Make it possible to hack on new (extension) modules for the
system without requiring a long compile-test cycle (which
kills my productivity when developing new modules)
o Reduce the number of languages a user needs to know to
develop PyOpenGL
+ Comes right down to it, I have so little time to work
on PyOpenGL that I really need to get to the point
where other people can do the work. Everyone who
wants to use PyOpenGL knows Python, only a fraction
know C...
Flexibility
o Make it possible to hook into the wrapping aspects of the system
+ e.g. register a handler for a data-type (e.g. a PyGame
surface, or a PyMedia data-stream) such that it can be
efficiently handled as a texture/array data-type
o Make it easily possible to include modules to which I don't
have access (really this is more of a "lower barrier to
entry" thing, but it means that people who have a 2.0 GL.h
header can provide 2.0 features without needing them to be
present on the machine compiling a binary distribution)
+ We can actually just try to find the entry point, and
if we don't, just catch the error... avoids lots of
"if opengl version > XXX" code
o Ready for PyPy when it matures (i.e. move the code up into
Python with as little C code as possible)
Cleaner design (hopefully)
o Tarn's design was heavily influenced by SWIG's
macro-expansion philosophy... it's a little hard for people
to follow, even when they've been working on it as long as I
have. It's elegant in many ways, but it's also a pretty
serious PITA for maintenance. And in the end, I just don't
like massively-nested macro-expansions!
o Eliminate the complex and fragile compilation scripts; have
2 or 3 extensions, something to kick off the Togl
compilation (assuming we still distribute it (likely)) and a
big block of Python packages that just get copied over
unchanged.
And there you have it, a quick explanation of why it's at least worthwhile to try building OpenGL-ctypes IMO. Oh, apologies for the formatting, I didn't think to post this until after Thunderbird had converted it into plain-text, and I don't really have time to reformat it this afternoon.
I'm glad to see this. After fighting around with trying to build PyOpenGL on Fedora Core 1 (unsuccessfully (it's the first time I've seen a build script get into an infinite loop), but it's OK since I have a working version on win32), I'm happy to vote in favor of a simpler build.
Also speed of loading, and download size.
When I did a prototype it was possible with ctypes to have a much smaller installed size. As well as a faster loading time.
I'm so glad you're working on ctypes pyopengl! It looks like you're getting quite the way through as well