Dave,
> | The cleanest way to resolve this so it never comes back is to include
> | glext.h in gl.h, bite the bullet and port whatever code breaks. (ducks
for
> | cover)
> |
> | If we want glext.h to become a cross-platform thing, then we need a
> | cross-platform symbol. On this much we agree.
>
>David Blythe writes:
> Mark & Michael can you comment on what nvidia's plan is wrt
> extension definitions on Windows? I'm guessing that the
> plan was to include a glext.h on windows too, but not
> modify the system version of gl.h
Yes, we'd like to release a <GL/glext.h> for Windows. Preferably, we'd like
to be able to supply a single <GL/glext.h> that works for both Windows and
Linux.
> It would seem that
> GL_HAS_GLEXT or some other symbol wouldn't be in the
> Windows gl.h nor would an include of GL/glext.h and
> application writers would still need other mumbojumbo
> to achieve portability. True or False?
My hope was that either:
1) We (the ARB as a whole) could convince Microsoft to update their
<GL/gl.h> for the OpenGL 1.2 timeframe to include some level
of adoption of some <GL/glext.h> standard (maybe that's too
far-fetched).
--or--
2) Vendors could (individually or by coordination) supply a <GL/glext.h>
for Windows. While Microsoft might not support GL_HAS_GLEXT,
programs could still use
#ifdef GL_HAS_GLEXT
#include <GL/glext.h>
#endif
but defining GL_HAS_GLEXT would be done manually with a
/DGL_HAS_GLEXT or similar option.
> Note, my preference is to include glext.h in gl.h on linux and
> fix the broken programs too with the assumption that linux
> provides the preferred model for how things should work.
I agree that <GL/glext.h> should simply be included by <GL/gl.h>.
- Mark
