In your message of 23 November 1999 you write:
> 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.
I don't think this will be a big problem. glext.h has to include gl.h
first to get the OpenGL types, like GLint. Hence gl.h defines all the
extensions that a vendor implemented, and then glext.h checks for
this.
> > 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.
Have we defined yet, which extensions are guaranteed to be in the
libGL.so ?
> > 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.
I think that this will be overkill. Let's not create soemthing
overcomplicated here.
> > 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.
Ok.
Now still one lingering issue. The document states that even a
libGL.so.1.1 has to have include files that export OpenGL 1.2, GLU 1.3
and GLX 1.3 entry points. Is that really wise to do ? If so, is there
a prototype available, that I would use for our include files ?
- Thomas
PS: If anybody is intrested, I could e-mail our samples of
gl.h/glext.h/glx.h that would conform to all requirements in the
document (assuming there is a glXGetProcAddressARB). Might be
intresting for ISVs to try out, whether this meets there needs.
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
