Jon Leech wrote:
> [...] The other set of .spec files [...] tries to be much more complete
> in extension coverage (although this is quite difficult because of the
> pace at which some vendors release extensions, often without telling me).
Well, that's the main reason I wanted to rely on that set for my OpenGL
binding: Let other people do the hard work of keeping everything up to
date... ;-)
> [...] enum.spec really only has *one* purpose right now - keeping track
> of which enumerant ranges are assigned to which vendor. So it is mostly
> ordered numerically with range<->vendor mappings identified. Where known,
> individual enum usage within the assigned ranges is tagged - but that's
> really just intended as additional documentation.
I didn't know that. But for a documentation it is rather good and quite
usable in terms of automatic processing.
> [...] It is certainly possible to restructure the spec files and
> generator scripts to do away with some of the replication, though it's
> hard to see how to collapse enum.spec and enumext.spec together short of
> just stuffing it all in a relational database :-) It would certailny be a
> lot of work [...]
I'm not sure if it is really that much work: What is missing for the enums
is basically something like the 'version' resp. 'category' properties of
functions (see gl.spec and friends). If that could be achieved in a
backwards-compatible way it would help quite a lot.
> [...] I hope that makes at least some sense.
Yes, thanks a lot for the info.
Cheers,
S.
--
Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461
BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring
mailto:Sven_Panne@xxxxxxxxxxxxxxx http://www.betaresearch.de
|