On Tue, 21 Mar 2000, Michael Gold wrote:
> By definition, an application which is "legal" according to the oglbase spec
> should not have any problems when confronted by glext.h. Any app which does
> not comply to oglbase has no guarantee of working anyway...
Well, I consider it very bad form for an oglbase compliant implementation
to break programs that have been working just fine on pre-existing implementations.
I've written hundreds of OpenGL programs for Linux and many of them would
fail if glext.h was forced into gl.h - I'd have to object strongly to
anything that would break all those applications.
In the end, we still want legal OpenGL programs (even if not legal oglbase
programs) to compile and run.
> the fact that
> some legacy apps might compile w/o glext.h but fail with it indicates that
> they are not oglbase compliant.
Indeed - but they are not required to be compliant - they may just be
programs I wrote for my own private use. There are thousands and
thousands of people happily writing OpenGL code for Linux without
the help of oglbase - and you simply cannot piss all of them off by
breaking their code.
> 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.
I'm vehemently opposed to including glext.h into gl.h by default. It's
completely unacceptable because it would entail editing hundreds and
hundreds of existing, working, OpenGL programs that are already out there
for Linux - and make it harder to import (for example) SGI-based OpenGL
programs into a Linux environment.
Programs which use OpenGL extensions and which wish to BECOME oglbase
compliant will need to be edited anyway because they'll need to use
the new glGetProcAddress stuff. Tacking in the #include <glext.h>
thingy at the same time is no big deal by comparison.
Don't forget that this oglbase specification is going to take a
fair amount of time to propagate across the entire installed
base of Linux users. There are still people out there writing
Mesa programs with libc5 for chrissakes!
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
