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)
> 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?
But it's NOT just a handful. There are thousands and thousands of OpenGL
programs out there that know nothing of oglbase.
> And don't you want these legacy apps
> to use extensions where available anyway? in which case you must still
> modify them.
Not if gl.h continues to define extensions for things that are locally
supported. That's what we agreed would happen on the first trip around
this loop.
> 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.
But this is *LINUX* - think about the culture you are stepping into here!
By far the vast majority of programs are distributed in source code
form - and the './configure ; make' mechanism is sufficiently
easy that lots of non-programmers can compile and install source-only
applications. When legacy apps fail to compile 'out of the box', those
people will be utterly unable to figure out what to do to fix them.
> > 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.
I want the app to continue to work when recompiled. If it ceases to use
an extension that worked previously - then that's not great news - but
it's not a total disaster. What *is* bad news is having to personally
go back through about 5 years of OpenGL programming fixing up code
from way back. My boss is going to be extremely unhappy when I tell
him that I need 200 man-hours to do that!
You are making it sound like OpenGL under Linux is very new - it's not!
At any rate, we can make it so existing apps will continue to use
the extensions they are currently using by simply continuing to ship
the CURRENT gl.h unchanged. That's why the oglbase spec requires
that extension definitions are guarded by:
#ifndef GL_EXT_whatever
...we thought about this and figured it all out MONTHS ago.
> 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.
But it's not minor. You are dooming Linux to be utterly incapable
of compiling existing OpenGL programs that use extensions. Remember
that I can currently pick up a program I wrote for a non-Linux (and
hence DEFINITELY non-oglbase) machine and compile it. Even after
oglbase becomes recognised, what you are proposing would make it
much harder to port OpenGL code from other UNIXen onto Linux.
That's "A Bad Thing".
> > 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".
I guess it depends on how much OpenGL code you've written for Linux.
I have several million lines of the stuff spread across several projects -
and I *don't* want to go back and fix it all.
> 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.
Yes - exactly.
It would be nice if we could periodically tear up all that old stuff
and throw it all away - but we can't. That's why Win2000 still uses
/r/n line terminators, C++ still has goto, UNIX still calls it's directory
listing command 'ls' and we still have Fortran compilers.
I don't think it's much to ask to add one additional header file to
new applications in order to avoid existing, *legal* OpenGL programs
(and future OpenGL programs ported from elsewhere) failing to compile.
When you start off a project you always end up with a stack of a dozen
stoopid headers you have to include - adding one more to that stack is
zero burden IMHO.
> The good news/bad news is that OpenGL is not in widespread
> use on Linux at this time,
Good God man...Where have you *been* the last few years?
Not widespread in commercial terms perhaps - but in terms of little
programs written by biologists, statisticians, etc. A LOT of OpenGL
programs have been ported from low-end SGI machines onto Linux - there
are a ton of individual programs. Just because you can't buy them (or
download them even) doesn't mean they aren't there. The sum total
of human effort that's entailed here is not measured by the volume
of sales or the net cash flow - it's the number of source files.
The vast majority of lines of code written in OpenGL for Linux
will never be run on anything but the machine it was compiled
on. A tiny, tiny fraction of games developers (mostly) will
need the OGLBASE stuff - the results of their efforts is
vast amounts of sales, revenue, profits, etc - but the amount
of source code that needs to have #include <glext.h> is still
gonna be tiny compared to all the other uses of OpenGL under
Linux.
Until the oglbase specs make it into the RedBook, the vast
percentage of programmers out there won't even know of it's
existance...and they don't need too either if we do it right.
We need to make it possible to write binary portable code
for those who need it - but not at the expense of the people
who don't.
> ...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. ;-)
I'll ask my son - I'm sure he'll forgive us....global warming
though - that's a different matter :-)
If Mesa was six months or a year old - I might agree - but it's
MUCH older than that - and it goes beyond that.
Having to hack around every program that's imported from Sun, SGI,
Intergraph, etc, etc so it'll compile means that if Linux truly
does become the One True UNIX then virtually every OpenGL program
ever written will ultimately have to go through this process.
Writing a standard to make OpenGL programs more portable within
Linux - that ends up making most OpenGL programs fail to compile
under Linux is just plain silly.
*PLEASE* don't do this.
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
