Jon,
> > Without GL_HAS_GLEXT, it is impossible to portably know if <GL/glext.h>
> > can be included without a compile-time error.
>
> Au contraire; the symbol has no utility for portable source code.
> For an oglbase environment, it is not needed. For any other environment
> (read: Windows, MacOS, vendor UNIX), it is highly likely that the symbol
> will not ever be put in gl.h, *just as no other guarantees of oglbase
> are meaningful for such an environment*.
That's fine if no other environment defines the symbol. The point is
if the symbol is defined, then <GL/glext.h> can be included. If it is
not defined, the safe assumption is to not include <GL/glext.h>
> Furthermore, since this symbol does not follow GL naming conventions
> and is not associated with an extension, it is more than meaningless:
> people may already be using it for unknowable other purposes.
Ok, can you suggest a better name? I only suggest GL_HAS_GLEXT because
1) it begins with GL_
2) it is an extremely unlikely name for a core OpenGL token
3) it is short and indicates briefly the symbol's purpose
I note the GL_VERSION_1_1 and GL_VERSION_1_2 are not associated with
an extension. Do these symbols follow GL naming conventions?
> Finally, if the symbol exists, people will start using it as a
> binary on/off switch to control all manner of behavior above and beyond
> glext.h. For the perfect example of why this is a bad idea, simply
> remember the years-long transition period in which __ANSI_C__ was being
> defined by compilers that, in fact, were *not* ANSI C compilers but
> wanted to pretend they were - and the resultant ground truth that the
> symbol was, in fact, totally useless for the intended purposes for many
> years.
Good point, yet the problem with __ANSI_C__ was that it had too broad
a meaning. Did it mean that the ANSI C library was supported? Or did
it mean that prototypes were supported? Or did it mean that "..." was
supported? It meant lots of things so it did indeed get abused.
The point of GL_HAS_GLEXT is simply to indicate that <GL/glext.h>
can be safely included without risk of compile time error.
Your objection could be addressed by properly documenting the one and
only purpose of GL_HAS_GLEXT in the standard. I believe my suggested
wording did exactly that. Let me know if it needs clarification.
> Personally, I consider this issue closed until someone can provide a
> convincing argument as to why doing this has any utility to oglbase, and
> as to how the symbol is supposed to get inserted into e.g. Microsoft's
> <GL/gl.h> at any forseeable time in the future. Repeating the
> hypothetical benefits is not a convincing argument to me.
The point is exactly that the GL_HAS_GLEXT symbol never needs to get
inserted into Microsoft's <GL/gl.h>. If the GL_HAS_GLEXT symbol is
not defined after including <GL/gl.h>, then the safe assumption would
be to not include <GL/glext.h>.
I'm not sure what you mean by "hypothetical benefits". If the benefit
was hypothetical, I would agree with you. But the problem that GL_HAS_GLEXT
solves is quite real for an OpenGL source code distribution (such as GLUT)
that
wants to compile without errors on as many OpenGL implementations as
possible.
The real problem that I want to avoid is the following:
% gcc -c foo.c
foo.c:3: GL/glext.h: No such file or directory
There's nothing hypothetical about this fatal compiler error to me.
Yet the compiler error can be avoided with:
#include <GL/gl.h>
#ifdef GL_HAS_GLEXT
#include <GL/glext.h>
#endif
/* Remainder of the OpenGL source code uses extension #defines to determine
whether to use various compile-time extension tokens. */
An alternative that would give a pointer to the updated headers would be
something like:
#include <GL/gl.h>
#ifdef GL_HAS_GLEXT
#include <GL/glext.h>
#else
#error Please get a <GL/gl.h> and <GL/glext.h> from www.opengl.org
conforming to the oglbase standard
#endif
Incorporating GL_HAS_GLEXT seems a simple matter. Even if you doubt the
rationale for the suggestion, surely you can agree that there is no
serious disadvantage to including GL_HAS_GLEXT as part of the standard.
If you object to the name, please suggest a better name.
- Mark
