> > 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". Where do we want the burden to be? On all future oglbase
programs from now until eternity, or on the handful of legacy apps which may
or may not have problems with glext.h? And don't you want these legacy apps
to use extensions where available anyway? in which case you must still
modify them. Remember, existing binaries won't break, only if/when you go
back and recompile them. On the chance that you recompile a legacy app and
it fails to link because of extensions, a simple change to the makefile to
disable extensions allows you to compile it, if you don't feel like adding
the extension support today.
> 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.
You are makingh wayu too much of this. Either you want these ported apps to
use extensions or you don't. If you do, you must edit them anyway. If you
don't, part of the port is defining a symbol in a makefile.
This is about doing what's right long term, and enduring possible minor
short term pain, versus making a short-sighted decision for a small number
of legacy apps and burdening every future application with additional
requirements.
> 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.
Well, that's where we disagree. Add an extra header to every file or your
global header, and risk that the file exists on some platforms and not on
others, versus adding one symbol to a makefile for the legacy apps which are
affected (and I promise not all will be, i'll assert that most will not). I
guess you and I have different ideas of what constitues a "big deal".
> 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!
And until it arrives, people won't be affected in any case.
If glext.h is properly written, including it twice won't cause a problem for
anyone who explicitly includes it. The only compatibility issue I have
heard is yours, that extension entry points may not link, and that is quite
simply addressed by my proposal.
I think our disagreement stems from the fact that we are coming from
different places - you are an old-time Linux/OpenGL developer with a code
base to protect, whereas I am looking at this as a new beginning and am
trying to make what I consider the best decision for the future. The good
news/bad news is that OpenGL is not in widespread use on Linux at this time,
at least not compared with what we hope/expect it to be. As such, the early
pioneers may have to endure a minor transition so that it will be a better
world for our children. ;-)
-- Michael
