Michael Gold wrote:
> 
> John wrote:
> > 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.

A "matching" gl.h and glext.h are mandated by the standard, as Jon has
pointed out.


>  - 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 think someone suggested that gl.h include glext.h but that was shot
down for some reason.  Anyone remember why?


> 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.

I wasn't happy about doing that either but I _had_ to do something.
I was waiting on a number of other items for XFree86 4.0 but they didn't
arrive on time either (such as a complete gl.spec file and GLX 1.3 token
values) so I had to take things into my own hands.

-Brian

Reply via email to