> 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!
> By my estimate, I've received email from 2000-3000 Linux/Mesa
> users over
> the years. I bet that's a small fraction of the entire user base.
> Mesa's been included with several Linux distros for some
> years. I know
> of several large installation bases of Linux/Mesa in universities and
> research labs. Basically every 3D app/game/utility on Linux
> uses Mesa.
>
> If we don't have some reasonable amount of backward compatibility with
> that installed base you can bet I'll be the one to hear about it.
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.
> 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?
> 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.
Steve, does this address your concerns?
-- Michael
