[EMAIL PROTECTED] (David Blythe) wrote:
> | > - 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?
>
> This seems like the obvious answer to me too. Anyone making progress
> on remembering the objection?
> david
Using grep I found the following
On Wed, 07 Jul 1999 07:57:12 -0700 "Michael I. Gold" <[EMAIL PROTECTED]>
made the observation
> #include <GL/glut.h>
> #include <GL/glext.h>
> doesn't work unless glext.h also pulls in windows.h
I saw no refutation of this.
On Tue, 7 Sep 1999 09:54:04 -0700 Jon Leech <[EMAIL PROTECTED]>
observed
> On Tue, Sep 07, 1999 at 08:19:57AM -0500, Stephen J Baker wrote:
> > Yes, I agree that the contents of glEXT.h should not be literally
> > inside gl.h - but I see no reason not to put #include <GL/glEXT.h>
> > inside gl.h in order to avoid breaking existing programs that use
> > extensions - but which do not know to #include <GL/glEXT.h>
> The primary reason is that people who *support* their GL
> implementation will tend to be unwilling to introduce a dependency on a
> header file maintained in an ad-hoc, outside their control fashion. That
> would include, for example, SGI.
> The secondary reason is that there already is a glext.h and people
> already are including it in their apps separately from gl.h.
> It should not break anyone's existing programs to include glext.h
> separately: portable code cannot assume that *any* extensions are
> defined in gl.h, programs that are not portable will continue having a
> dependency on existing vendor header files, and glext.h should be
> written in such a fashion that it doesn't introduce any
> incompatibilities with existing vendor gl.h files when both are
> included.
On Tue, 07 Sep 1999 10:27:14 -0700 [EMAIL PROTECTED] acquiesced to
Jon's reasoning
> | The primary reason is that people who *support* their GL
> | implementation will tend to be unwilling to introduce a dependency on a
> | header file maintained in an ad-hoc, outside their control fashion. That
> | would include, for example, SGI.
> |
> | The secondary reason is that there already is a glext.h and people
> | already are including it in their apps separately from gl.h.
> I'm willing to go along with that reasoning.
> Allen
On Tue, 7 Sep 1999 19:30:19 -0700 Jon Leech <[EMAIL PROTECTED]>
put the final nail in the coffin
> On Tue, Sep 07, 1999 at 01:24:59PM -0500, Stephen J Baker wrote:
> > SGI are transitioning to Linux - they'd better get used to 'ad-hoc'
> > and 'outside their control' :-)
> SGI has its own Linux distribution. Red Hat does. SuSE does. Lots of
> groups do, and nobody doing commercial support wants to include random,
> untested bits of unknown provenance (which, from the viewpoint of the
> support crew, is exactly what glext.h is) in what they support.
Your faithful archivist,
Jim
---------- ---------------------- --------------------
| Jim Cobb | 540 Arapeen Dr. #100 | [EMAIL PROTECTED] |
| PTC | Salt Lake City, UT | (801)-588-4632 |
| | 84108-1202 | Fax (801)-588-4650 |
---------- ---------------------- --------------------
An education isn't how much you have committed to memory, or even how
much you know. It's being able to differentiate between what you know
and what you don't. -- Anatole France
