On Tue, Nov 23, 1999 at 10:21:23AM -0700, Thomas Roell wrote:
> While updating our libraries to be fully compliant with the suggested
> standard, I ran across a problem with glext.h.
>
> The idea of this header file was to include all the extensions that
> were out there in order to allow better compilte-time testing.
>
> So what I would do for our include files, is to put all the extensions
> that our libraries support into gl.h, and all the other ones,
> including the ones we support into glext.h. Now for the ones that we
> don't support in the library, this gets tricky:
>
>
> Variant 1:
> --------------------------------------------------------------------------------
> /* EXT_compiled_vertex_array */
> #ifndef GL_EXT_compiled_vertex_array
> #define GL_EXT_compiled_vertex_array 1
>
> #define GL_ARRAY_ELEMENT_LOCK_FIRST_EXT 0x81A8
> #define GL_ARRAY_ELEMENT_LOCK_COUNT_EXT 0x81A9
>
> extern void glLockArraysEXT (GLint first, GLsizei count);
> extern void glUnlockArraysEXT ();
> #endif
> --------------------------------------------------------------------------------
>
>
> Variant 2:
> --------------------------------------------------------------------------------
> /* EXT_compiled_vertex_array */
> #ifndef GL_EXT_compiled_vertex_array
>
> #define GL_ARRAY_ELEMENT_LOCK_FIRST_EXT 0x81A8
> #define GL_ARRAY_ELEMENT_LOCK_COUNT_EXT 0x81A9
>
> typedef void (*glLockArraysEXTProc)(GLint first, GLsizei count);
> typedef void (*glUnlockArraysEXTProc)();
> #endif
> --------------------------------------------------------------------------------
>
> Ok, the issue with variant 1 is that I define "GL_EXT_compiled_vertex_array" to be 1.
> This implies as to normal rules that the API entry points would be
> present in the core library, which of course they are not. Variant 2
> is also not really great, as although it defines all the tokens
> correctly, and would define the types for the functions for retrieval
> by glXGetProcAddressARB() it does not define
> "GL_EXT_compiled_vertex_array", which means and application cannot
> check for compile-time availablity.
>
>
> Now my couple of questions:
>
> 1. Which is the right way to do this ? Define
> "GL_EXT_compiled_vertex_array" to be 1 and have the "Proc"
> typedefs ?
The #define as used traditionally doesn't mean quite what we want,
true. As used on Unix systems in the past, it means both that (a)
prototypes and enums are available at compile time and (b) entry points
exist at link time. I think an oglbase compliant application will need
to use additional compile information to determine whether the entry
points are static or dynamic, such as the oglbase version number or
perhaps whether or not GL_ARB_get_proc_address is #defined.
Because gl.h and glext.h will come from separate sources, it's vital
that they don't step on each other. If extensions get declared in both
places they had better use precisely the same declaration conventions -
this is a big part of why I want to lift all extensions possible into
glext.h, so the vendor gl.h doesn't need to include them.
> 2. Should there be another defines somewhere saying that the
> core-library doesn't support this ?
Per above, an oglbase version number will determine a particular set
of extensions that are in the link library. Others may be as well, but
using them in that fashion guarantees the app is not oglbase compliant.
> 3. Is the typing for the API entries correct, or should we use the
> Microsoft style ?
>
> #if defined(linux)
> #define APIENTRY /**/
> #endif
>
> /* EXT_compiled_vertex_array */
> typedef void (APIENTRY * PFNGLLOCKARRAYSEXTPROC) (GLint first, GLsizei count);
> typedef void (APIENTRY * PFNGLUNLOCKARRAYSEXTPROC) (void);
The MS naming convention is ugly, but I want us to have a single
glext.h that works on multiple platforms, so people can just be pointed
at it on opengl.org in the standards section (we will have a standards
section once we have an oglbase standard :-) It also lends applications
some hope of writing crossplatform code using the same typedefs. I think
we should also include prototypes for the same functions, whether
available statically or not (some apps will probably create their own
entry points for the missing functions).
Perhaps we could have both Proc and PFN naming conventions? It's a
bit more verbose, but glext.h will probably be automatically generated
anyway.
> 4. Is it permissable for glx.h to include <X11/Xlib.h> and <X11/Xutil.h> ?
Yes, though as David Blythe earlier pointed out, probably not any
other X headers (the SI and the open source GLX from the SI has Xmd.h as
well - it will get pulled).
X commits horrid namespace pollution, alas, but if you're using GLX
you pretty much have to have the X headers in the same compilation unit
anyway. This is something to pin down in the oglbase specification, too.
Jon Leech
SGI
