On Wed, 22 Mar 2000, Thomas Roell wrote:
> In your message of 21 March 2000 you write:
>
> > I can think of one reason why you must NOT #include glext.h from
> > within gl.h and that is that it could wreck existing programs
> > that conditionally compile extension code on the assumption
> > that they will be compiled and run on the same machine.
> >
> > #ifdef GL_EXT_something_or_other
> > glSomethingOrOtherEXT () ;
> > #endif
> >
> > Since glext.h defines ALL extensions for all machines, an
> > existing program that was only intended to run on the machine
> > it was compiled on would certainly break if glext.h were
> > rammed down it's throat by virtue of forced inclusion within
> > gl.h.
>
> Correct. As far as we discussed before, glext.h MUST include gl.h.
I'm not sure about that - but gl.h must NOT include glext.h - I'm
not sure I care whether the reverse is true.
One thing though is that public headers for existing libraries
(such as glut.h) shouldn't include glext.h either - for the same
reason that gl.h must not.
> Also remember that glext.h should not declare extenion functions, but
> only define the pointers to a specific function as they are queried by
> glXGetProcAddressARB(). So normally there wouldn't be any declarations
> for those extension functions.
Er - yes, I guess you're right - so it breaks at compile time rather
than link time - who cares? Old (but legal) code still won't compile.
I'll also point out that some of the examples that come with GLUT
will fall foul of this - it's not just some poorly thought out code
that I might have written!
> So I guess we are back to Jon's original point that a compliant
> implementation always ships a glext.h by default.
Yes...absolutely it must...even if it's just an empty file or a
very old subset of the 'current' version.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
