On Tue, Mar 21, 2000 at 10:12:02AM -0800, Michael Gold 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?)
glext.h is unusual in that it's supposed to be frequently updated so
it defines all existing extension interfaces - e.g. downloading a new
hardware driver module with new extensions means that you need to go get
the latest glext.h too. The X and Linux distributions aren't going to
tie their update schedule to hardware drivers and they will usually lag
glext.h by at least a bit. This reflects the loadable module paradigm
where you get the link library and glXGetProcAddress() from one place,
and the actual driver from another. And of course glext.h is supposed to
keep being useful outside the oglbase and Linux contexts, too.
I could kinda see a case to #include glext.h in gl.h in the oglbase
environment only, but it raises problems for whomever is providing gl.h
since glext.h is expected to be replaced over time - replacing system
components is a nightmare for support people.
Jon
