On Tue, 2008-04-22 at 12:18 -0700, Mark Glines wrote: > Ok. So if the OpenGL and crypto code didn't have to generate custom C > files, they wouldn't have to have all the extra infrastructure, right? > Just a test that gets "skip_all"ed if the library can't be loaded at > runtime, like pgsql has, no detection nonsense, no generation > nonsense, no config-script testing nonsense. > > So is that the preferred method of implementing bindings for C > libraries? Or is there such a thing as a "preferred method", to begin > with?
At least the OpenGL code pretty much has to generate some C files. I would like to have used generic Parrot NCI everywhere, but GLU and GLUT both have callbacks that don't fit into Parrot's NCI callback model. Thus, C wrappers are required to make the callbacks work. Also, different GLUT vendors/releases support very different subsets of the GLUT API, so either the C code has to be a mess of interlocking #ifdefs, or I have to generate the C files. Then there's the #defines and function prototypes (from which to compute the NCI sigs needed). To maintain portability, these need to be parsed from the system headers. (Yes, in theory we could preparse the OpenGL ARB's "standard" headers and ship the result, similar to not requiring everyone to have yacc. However, we'd still need to ship the generator code anyway, people would need to know how/when to run it when headers are updated, and the result would be brittle, constantly out of date, and incorrect on systems whose extensions have not yet been ARB approved.) In other words, in theory the OpenGL bindings *could* avoid generating C code at Configure time -- but this would be a bad thing, not an improvement. -'f
