On Tue, May 09, 2000 at 07:44:38AM -0500, Stephen J Baker wrote:
|
| > Code that compiles under this gl.h must define its own function
| > typedefs even for the extensions covered in gl.h.
|
| But most existing code won't be using function typedefs because we have
| no glGetProcAddress (yet).
Essentially all the code coming from the Windows world will be using
wglGetProcAddress and function typedefs, as that's the standard
approach there.
(And Mesa supports glXGetProcAddressARB, so there are already some
users even in the Linux world.)
| > It's common to use
| > the conventional PFN* names for these typedefs. If the code is now
| > modified to include glext.h, it will fail to compile because those
| > typedefs are redefined.
|
| ...but that's a non-problem because you are already modifying the
| code for ABI compliance and you can take out your own PFN's and let
| glext do the work.
Maybe I should express it another way: You can have upward
compatibility, or you can have the ability to include glext.h, but you
can't have both; you'll need to modify your source code.
That's a consequence of the way existing gl.h's work, so there's not
much we can do about it -- other than establish rules and conditional
compilation for gl.h so that it can't reoccur in the future.
| But for existing programs, there is no change! No change at all...how
| can that possibly be incompatible?
As long as you configure your gl.h in compatibility mode, and you
don't include glext.h, you can have upward compatibility. Otherwise,
you need to make changes to your code.
| Right now, there are precisely TWO "vendors of gl.h" Mesa and XiG...
| with Mesa being in *huge* majority (15 million versus however many
| XiG sold...10,000 maybe?).
My (possibly flawed) understanding is that both HP and IBM also ship
gl.h. In general, UNIX vendors who are moving their products into the
Linux space might be expected to retain compatibility with their
earlier UNIX versions of gl.h.
That may not be a compelling argument, but the different versions of
Mesa's gl.h and libGL.so that have shipped with the various Linux
distributions are sufficient to exhibit all the problems we're
concerned about.
| Except that this is the case currently. Programs *do* happily compile
| with either gl.h that currently exists.
Speaking from my own experience, getting glean to work with the
various gl.h's that are floating around has been a trial-and-error
process. Sure, it compiles now, but mostly because I finally gave up
and pulled a full set of extension information into a separate
namespace where I could control it. Not a good solution in the long
run.
Allen
