In your message of 22 March 2000 you write:
> On Wed, 22 Mar 2000, Michael Gold wrote:
>
> > > > I'm not sure this is a compelling argument
> > > > against including glext.h unconditionally.
> > > >
> > > > If you want to get fancy, gl.h could have:
> > > >
> > > > #if !defined(__GL_NO_EXTENSIONS)
> > > > #include <GL/glext.h>
> > > > #endif
> > > >
> > > > so legacy apps could continue to work by adding
> > > -D__GL_NO_EXTENSIONS to
> > > > their LCDEFS.
> > >
> > > No, no, no - if anything, it would have to be the other way around.
> > >
> > > -D__GL_NEED_OGLBASE_EXTENSIONS
> > >
> > > ...in oglbase programs, nothing in existing apps...but then that's no
> > > different than just including glext.h directly into the app.
> >
> > ... which is why I think its wrong. I don't want to cripple the utility of
> > oglbase by adding wacky requirements like this in order to use extensions.
> > They should just be there. The average programmer is not going to read a
> > spec and think "Oh i have to define BLAHBLAH in the makefile or I won't get
> > extensions".
>
> True - but it's not unreasonable to ask him to #include the file that
> defines those extensions. (IMHO)
Hmmm ... I start to think there might be some confusion. Let me
quickly summarize what I understand:
1. glext.h has only defines and function-pointer prototypes,
since all functions are retrieved by glXGetProcAddressARB.
2. If glXGetProcAddressARB is available, then after including
glx.h, GLX_ARB_get_proc_address is defined.
So why not simply key off the existance of glext.h off of
GLX_ARB_get_proc_address ? All extension functions that are callable
directly via functions are in gl.h anyway, so only if
glXGetProcAddressARB is available, glext.h make sence.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
