On Fri, 24 Mar 2000, Michael Gold wrote:
> It seems to be, based on Brian's post, that the con to including glext.h
> automatically is not a big issue in practice because the old extension entry
> points are still available in the DSO.
That's wrong for two subtle but important reasons:
1) It's only Mesa that guarantees to put all of *Mesa's* old extensions
into Mesa's libGL.so - will the upcoming nVidia OpenGL do the same?
Will Mesa include all of nVidia's extensions? Where do you stop?
Programs that use other Linux OpenGL implementations that don't include
all of Mesa's extensions will break - and vice-versa.
If you want to propose this then you have to write down all of the
extensions of ALL current Linux OpenGL implementations (not just
Mesa) and mandate that ALL future Linux OpenGL implementations
include them all as dummy entrypoints. Yuk!
I want that written into the oglbase spec if we are stoopid enough
to go this route.
I agree that this is a one-time problem - but it's not as small
as you seem to imagine.
2) It doesn't help programs ported from other platforms either in the
past or in the future. I have programs that were written on SGI
machines that make use of SGI-specific extensions. They currently
compile just fine under Mesa and XiG because the SGI extensions are
not defined in gl.h - however, those SGI extensions are not in
Mesa's libGL.so - nor in XiG's or nVidia's libGL.so
My existing code base of several millions of lines of code will need
to be hacked - I'm far from being alone in this.
This isn't a 'one time' problem that'll go away after a few months.
Programs will continue to drift in from other OS's right up to
the day when Linux takes over the world and becomes The One True OS.
I'm not holding my breath. Each time someone ports a program from
another platform (and bearing in mind that those people are most
often the Linux newbies), there will be an inexplicable problem
and a request for help from the Mesa mailing list.
> * I know one more issue, but the window of opportunity for failure is
> becoming increasingly small. If an app was written to use an extension
> which was not available on Linux, it wouldn't have attempted to use it on
> Linux. But with a new all-encompassing glext.h, it may now try to use this
> extension and have link errors. Our exposure is now limited to apps which
> use the extensions which were not available on Linux/Mesa but were on other
> platforms.
No! Programs that are currently running under Mesa that were originally
running elsewhere are vulnerable. Since a LOT of people moved their code
from low end SGI/IRIX machines to PC/Linux boxes when the cost of good
3D hardware on PC's dropped through the floor, there are a TON of those
programs out there and most of them will break if glext.h is included
into gl.h.
OpenGL has a defined extension mechanism - by suggesting we break that,
we are destroying some part of OpenGL's portability. That's an
irresponsible step IMHO.
> If we can agree that automatic inclusion of glext.h is the _simplest_
> solution, modulo this legacy app issue, then we must decide, if the legacy
> problem is diminishingly small, what is our threshold of pain?
Which in the end is the only thing we disagree on.
I'm shouting and screaming about this because the amount of personal
pain that's going to spill over your threshold is more than I want
to bear.
> Most legacy apps will continue to compile/link just fine because of the
> measures Brian took to ensure this.
You are mistaken.
> Only a few will have any issue at all,
> and they can be fixed by adding a single define to a makefile if the author
> _really_ doesn't want to port to oglbase.
>
> Lets just do it and get it behind us. Small short term pain, Big long term
> gain.
I strongly disagree with that 'pain' assessment:
* HUGE short term pain (thousands of broken programs the day we
turn this on - *lots* of confused users on Mesa mailing list
and XiG customer support).
* Lesser long term pain (continuing import of ported programs
that fail to link for suprising reasons).
* Almost invisible long term benefit (not having to conditionally
include glext.h). Notice that this benefit is realisable only
by people who care about *binary* compatibility across Linux
OpenGL implementations AND who want their code to work on
non-Linux or pre-oglbase Linux via source code compatibility.
If we did it without glext.h included into gl.h then:
* For people who only care about source code compatibility,
this whole oglbase thing is just complexifying the problem
and the existing OpenGL extension mechanism works
just fine. (No pain)
* For people who don't need their code to work with pre-oglbase
and/or non-Linux systems, they can just include glext.h
unconditionally. (One line of code pain)
* For people who *do* need their code to work with pre-oglbase
and/or non-Linux systems - and yet who *also* want binary
compatibility across post-oglbase Linux - they can just
include glext.h conditionally using the symbol we provide
for just that purpose (or use autoconf or something similar
as I'd recommend). (Three lines of code pain)
Notice that people who are experiencing the couple of lines of
code pain are also adding thousands of lines of code for all
the glGetProcAddress stuff - which (at least in the last case)
all has to be conditional.
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
