In your message of 10 April 2000 you write:
> On Mon, 10 Apr 2000, Thomas Roell wrote:
>
> > In your message of 10 April 2000 you write:
> >
> > > > The cleanest solution IMO is that gl.h should not
> > > > define any extensions when glext.h is in use.
> > >
> > > ...Or the prototype function pointer could be left outside of the guardian
> > > ifdef in glext.h since gl.h won't define function *pointers* only the
> > > functions themselves.
> >
> > This would cause a problem with gl.h implementations that include
> > function pointers for extensions supported directly in libGL ...
>
> Does anyone actually do that (other than under Windoze that is) ?
Yep. We (Xi Graphics) do so. Why ? We started shipping a preliminary
gl.h/glext.h about half a year ago. Of course with no compile-time
define that would indicate that glext.h would be included or not. Now
for compatibility reasons a few extensions are declared the old style.
An example would be EXT_texture_object. Some applications ported from
other UNIX platforms really do use those things. Now glext.h must
include gl.h to get all the type defines. So some extensions end up in
gl.h and some in glext.h. Hence in order to avoid redefinitions or
redeclarations, you have to include at least the function pointers in
gl.h for the extensions that are defined there.
Of course, the real clean way around all of that is to conditionally
include glext.h from gl.h, because then there is a way for gl.h to
figure out what to declare in what way.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
