[lsb-discuss] glext.h

[Wichmann, Mats D]

On Thu, Jun 16, 2011 at 1:00 AM, <Craig.Scott at csiro.au> wrote:

> Hi all. I have a question regarding the glext.h header that is included in
> the lsb SDK. This particular header is a bit special in what it provides.
> Specifically, it provides definitions of constants rather than function
> prototypes or variables, and these constants are all very well defined (dare
> I say "standard"?) for OpenGL extensions. In fact, the Khronos group even
> provide a glext.h that developers should be able to simply drop in to their
> build to replace or stand in for a missing glext.h on their system.
>
> What I'm wondering is if there is anything stopping the lsb from simply
> including this Khronos-provided glext.h header in the lsb SDK instead of the
> one it currently provides? The current glext.h is missing a lot of stuff,
> and this makes it harder for people who actually want/need to use some of
> the things it provides (like us!). More importantly for devs/ISV's though is
> that the glext.h provided by the Khronos group is really what is considered
> the "standard" or "canonical" version of the header. It should be completely
> platform independent - it is all just constants provided by #define's plus
> some types. If the lsb SDK could simply include the glext.h from Khronos, it
> would improve robustness of the SDK since that glext.h will be well-tested
> and will also be what devs/ISV's are expecting to be available anyway. There
> doesn't seem to be much point in trying to make the lsb build its own
> glext.h when a fully complete and more widely tested header is already
> available.
>
> Note that the gl.h header pulls in glext.h, which is where this whole area
> starts getting important. For us, we have to provide our own glext.h (which
> is an unmodified copy of the Khronos group's glext.h) because we need GL
> constants/types that it provides but which the lsb SDK version does not. We
> then use these at run-time to test for the presence of certain GL features,
> since the user's graphics driver will generally provide things beyond what
> the LSB formally covers. OpenGL provides safe mechanisms for doing these
> tests, but you need the contents of the glext.h header to use it and this is
> where having the fully populated Khronos-provided version of glext.h makes a
> difference.
>
> If you try to include the Khronos' glext.h after the lsb SDK's glext.h, you
> get symbol redefinition warnings, so it has to be one or the other. There is
> a symbol you can define before including gl.h to allow you to provide your
> own glext.h later and I have just reported a bug related to this in the LSB
> bug tracker (this bug currently prevents us from working around the
> incomplete glext.h provided by the lsb without using a fragile hack that
> depends on the name of the header guard used within the lsb-provided
> glext.h):
>

Humpf, I thought I replied to this.

As hinted in the bug, sometimes we stab ourselves with our own cleverness.
Normally we generate inclusions based on dependencies - if a header uses
off_t, the database will supply the name of the header that defines off_t to
the generator tool which will add the inclusion.  But sometimes that's not
sufficient, so there's a mechnism for indicating in the database that a
certain header should include another header.  It's done using a special
attribute of a Constant, but this special case does not honor another
special case applying to Constants - conditional protection.  So without
hacking on the script, I can't get the #ifdef protecting #include
<GL/glext.h> into the file.

When glext.h and glxext.h were imported, I guess only those constants that
seemed to have applicability were added.  There's nothing wrong with adding
a bunch more, but what version of these files are the appropriate ones to
capture?  We reference an ancient - neolithic, even - version of OpenGL
itself.  Is it correct to have very up to date extension headers?  I see the
very latest are GL_GLEXT_VERSION 70  (a constant we don't even define, sigh)
and GLX_GLXEXT_VERSION 32 (this one we define, and it has a value of 6).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20110617/f9d0e052/attachment.htm