On Fri, Mar 17, 2000 at 09:51:13PM -0800, Mark Kilgard wrote:
> 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*.
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.
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.
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.
Hm, perhaps I feel more strongly than I suggested in previous mail.
Jon (feeling a bit testy after 2 days of ARB meeting)
