On Mon, Aug 18, 2008 at 3:05 PM, Bart Botta 00003b@gmail.com wrote:
On Mon, Aug 18, 2008 at 1:29 PM, Luís Oliveira luismbo@gmail.com wrote:
Actually, I wouldn't mind seeing the per-function enums come back. Having compile-time warnings when we passed a bogus keyword was nice.
Sounds like a reasonable thing to have, if we can generate it easily (which we can't for GL3 at the moment, since there are not complete .spec files available yet).
OK, after looking at the full gl3 .spec files, it looks like we can't generate all of the function specific enums automatically. It looks like it has some of the older enums split out, but not sure if they include all the newer extensions or not.
Probably could build up a full set of enums, if we don't mind giving up on being able to completely regenerate the enums automatically.
I've been thinking that might be a good idea in general though (the not fully automatic bindings part), since GL naming isn't consistent enough to rely on the automatic stuff for new function names anyway, so currently adding new extensions requires a few passes of proofreading the generated bindings and editing the generator.
Does it sound reasonable to split the binding generation into 3 steps, only 2 automatic: First would parse the .spec files, tracking any enum groups defined in the file, approximately splitting up function names, etc. and write the results to some lispy format (reusing output of step 2 if available). Second step would be editing the generated data by hand, adding missing enum groups, fixing word breaks that the automatic code got wrong, etc. Third would be parsing the hand edited code to generate the actual bindings.
-b-