> I don't really understand why you object so strongly to GL_HAS_GLEXT.
> It seems a simple solution to something that clearly will be a problem
> for developers seeking highly portable source code. I'm not the only
> one who has expressed the strong need and desire for this simple
> mechanism. Brian Paul was nice enough to re-iterate his
> support for the
> idea.
I'd like to agree with Mark and Brian, I think this is a simple solution to a
real problem with very few downsides.
I'd also like to mention that when the ARB designed the extension mechanism for
OpenGL avoiding compile time problems was a major goal. To meet that goal we
mandated that every extension had to define an "Extension Is Present" symbol so
source code could test for the existence of the symbol and avoid any compile
time problems. It seems to me one could argue GL_HAS_GLEXT is just another
example of the aforementioned mechanism mandated by the ARB in service of the
goal to avoid compile time problems. GL_HAS_GLEXT is consistent with this
established convention, it differs only by being applied in a marginally
different context, but I believe remains consistent with the philosophy of the
ARB.
> > Nobody expects stdio.h to e.g. #define STDIO_HAS_VARARGS_H
Maybe not, but that doesn't mean its not a good idea. Managing includes in
portable source code is a pain in the rear precisely because of issues such as
which header file do you include. Currently most portable code has an almost
incomprehensible set of convoluted #ifdef logic surrounding header file usage.
Anything which would help bring order to this mess would be welcome at my end
;-) I'm not saying the above STDIO_HAS_VARARGS_H is a great example of how to do
this, just that there is a genuine problem and solutions are welcome.
John
