> I'd like to agree with Mark and Brian, I think this is a
> simple solution to a real problem with very few downsides.
Well, let me offer a few downsides then.
- Defining this symbol is no guarantee that glext.h actually exists on the
system. Ergo it doesn't reaally solve the problem, and is a somewhat klunky
non-solution.
- When I first invented glext.h, it was intending to solve the problem of
compilation under Windows, where MS supplied a gl.h that did not include
vendor extensions. Rather than overwriting the MS-supplied header file,
which was awkward from a source control standpoint, I created a header file
which was intended to reside in the application's tree (or in the systemn
include path w/o overwriting an MS-supplied header). The fact that this
file existed at all was outside the scope of a generic build environment and
as part of a local build environment, its conditional inclusion should
therefore be part of the local build environment (e.g. local.defs or the
application Makefile). From this viewport, adding a hint to gl.h that its
safe to include this header seems like the wrong paradigm.
- If gl.h knows glext.h exists, why not just include it from gl.h? And if
we're going down that road, why have a glext.h at all, the extensions could
just go in gl.h. (Remember that the SI was not open source at the time
glext.h was conceived, do we wish to revisit this decision?)
I am also somewhat concerned that this token was added to XFree86 4.0 and
Mesa, and is now being pushed as a de facto standard without any discussion.
I realize there were schedule pressures but such unilateral decisions in the
absense of debate should be discouraged, it undermines the standardization
process we are working so hard to maintain.
My $0.02.
-- Michael
