ogl-sample
[Top] [All Lists]

Re: [ogl-sample] doc/registry/specs/enum.spec, bug

To: ogl-sample@xxxxxxxxxxx
Subject: Re: [ogl-sample] doc/registry/specs/enum.spec, bug
From: Jon Leech <ljp@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 21 Mar 2002 01:06:51 -0800
In-reply-to: <3C960C6A.940836C3@xxxxxxxxxxxxxxx>; from Sven_Panne@xxxxxxxxxxxxxxx on Mon, Mar 18, 2002 at 04:48:58PM +0100
References: <20020318154322.GA16998@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <3C960C6A.940836C3@xxxxxxxxxxxxxxx>
Reply-to: ogl-sample@xxxxxxxxxxx
Sender: owner-ogl-sample@xxxxxxxxxxx
User-agent: Mutt/1.3.15i
On Mon, Mar 18, 2002 at 04:48:58PM +0100, Sven Panne wrote:
> "Marcelo E. Magallon" wrote:
> >  a little bug in doc/registry/specs/enum.spec: [...]
>
> <ShamelessPlug>
>    http://haskell.org/HOpenGL/spec_bugs.html
> </ShamelessPlug>

    A few general comments about the .spec files - there are actually
two different versions in the SI tree, one used for generating the
<gl.h> that corresponds exactly to what the SI source code implements.
The other set of .spec files - the one you guys are talking about - is
primarily for the extension registry and 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).

    gl.spec has occasional bugs that need fixing, and I'm taking a look
at Sven's patches, but it's very close to correct for the main intended
purpose - generating prototypes and function pointer types in glext.h.

    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. The stuff in
enum.spec that is *not* commented out is the original (pre-ABI) contents
of enum.spec, as used to generate the SI (e.g. core OpenGL 1.2) header
files.

    enumext.spec, OTOH, is used to generate the enumerant portion of
glext.h - so it only contains the things that are defined to be in
glext.h (because they may not be in any particular vendor's gl.h): core
1.2+ enums, and all extension enums.

    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 that isn't justified for the purposes we're using the spec files
for right now. I have some cycles free for maintaining the spec files
now, first time in a long while, so I'll try to merge in those of Sven's
patches that make sense over the next week or so.

    I hope that makes at least some sense.

    Jon Leech
    SGI

<Prev in Thread] Current Thread [Next in Thread>