Michael Gold wrote:
>
> > With all due respect, I think OpenGL (Mesa) is bigger on
> > Linux than you'd expect.
>
> Well, that makes me happy. :-) Keep up the good work!
Thanks!
> I'm not advocating that we make dramatic changes. The only compatibility
> argument I have heard against including glext.h by default is Steve's
> concerns about legacy apps breaking.
Right.
> > There's three things I'd like to point out which have some bearing
> > on this discussion about gl.h vs glext.h. In particular, the gl.h
> > and glext.h files in Mesa 3.3 and XFree86 4.0:
> >
> > 1) glext.h still has the normal extern function declarations that have
> > been in gl.h. For example:
> > extern void glPointParameterfvEXT(GLenum, const GLfloat *);
> > glext.h also has the Microsoft-style function pointers.
> >
> > 2) In gl.h I left in most of the extension declarations that have
> > always been there. i.e. I didn't move ALL the extensions
> > to glext.h
> > (yes, there are duplications).
> >
> > 3) libGL.so still contains many extension entrypoints. You won't get
> > a link/load-time error if you directly call glPointParameterfvEXT
> > in your code because that function exists in libGL.so.
> >
> > All future Linux/OpenGL/Mesa development should use
> > glXGetProcAddressARB.
> > But in the mean time, these three items will help ensure backward
> > compatibility with the existing applications, both at compile
> > and runtime.
>
> From your description then it sounds like the scenario Steve describes is
> not (or less) likely to be a problem in practice. If the prototypes are
> defined, there will be no compile errors, and if the EXT entry points exist
> in the dso, there should not be link problems either. Do you agree?
Yes. Exactly. I believe Steve and I are equally concerned about
maintaining compatibility with the installed base.
> > Not doing this would result in a support nightmare of which the very
> > thought sends a shiver down my spine.
>
> This is good news Brian, it sounds like you have anticipated the
> compatibility issues very well.
Well, when you're the one implmenting this stuff the details and problems
present themselves quickly.
-Brian
