On Mon, May 08, 2000 at 02:56:30PM -0500, Stephen J Baker wrote:
|
| Urgh! It's gotten all muddy again.
That's what I thought, too, until talking to people and reviewing the
archives showed that it wasn't ever completely clear.
| A) gl.h is essentially what it is today - it contains
| definitions only for those extensions that the local
| OpenGL supports. ...
So far, so good.
| ... glext.h is #included either instead
| of or after gl.h in applications that need it for ABI
| reasons. ...
Here's where the problems start.
For example, the gl.h shipped in RedHat 6.2 defines extension
enumerants (unprotected by ifdefs), defines extension function
prototypes (protected by ifdefs), and does not define extension
function typedefs.
Code that compiles under this gl.h must define its own function
typedefs even for the extensions covered in gl.h. 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.
We were attempting to maintain compatibility, but we failed because
gl.h defines things that we don't really want it to define, and lacks
definitions for other things that we need. The situation gets worse
in a multivendor environment, of course, because there are so many
variants of gl.h and no preprocessor symbols to help sort out the
differences. (And there are other failure modes, involving
prototypes, for example, that we haven't discussed here.)
We want to preserve the current semantics so that existing apps can be
recompiled easily. We also want to introduce new declarations (in
glext.h) to support new extensions and a more consistent compilation
environment. Finally, we want to have a universal distribution
mechanism for gl.h and glext.h so that the development environment can
be decoupled from the runtime environment. These requirements are to
some extent mutually exclusive, because there are many existing and
mutually-inconsistent versions of gl.h.
As far as I can tell, the only solution is for each vendor to modify
its gl.h so that a preprocessor symbol controls its behavior. One
option maintains compatibility, and the other provides more consistent
semantics that will work well with glext.h and oglbase-conforming
apps. Option A can't accomplish what we want, because we can never be
sure that code which compiles with one gl.h will compile with another.
Options B and C could make that guarantee, though.
| B) Exactly as (A) except that you can -DGL_OGLBASE (or something)
| and glext.h will then (and only then) be automatically #included
| into gl.h. It follows that by NOT defining that symbol and
| #including glext.h yourself, you can pretend that (B) is really (A).
| glext.h probably has to #include gl.h since it needs GLfloat, etc.
Clearly there's some uncertainty about the original proposals. Do we
all agree that glext.h includes gl.h, for example?
| ...
| So, in terms of your ABI-compliant code:
|
| -------------------------
| A) #include <GL/glext.h>
|
| *OR*
|
| #include <GL/gl.h>
| #include <GL/glext.h>
Modulo the problems discussed above...
| -------------------------
| B) #define GL_OGLBASE (or '-D' in your Makefile)
| #include <GL/gl.h>
|
| *OR*
|
| #include <GL/glext.h>
|
| *OR*
|
| #include <GL/gl.h>
| #include <GL/glext.h>
| -------------------------
| C) #include <GL/gl.h>
| -------------------------
|
|
|
| But for existing code that uses OpenGL extensions in the time-honored way:
|
| -------------------------
| A) #include <GL/gl.h>
| -------------------------
| B) #include <GL/gl.h>
| -------------------------
| C) #define GL_OGLBASE_INCOMPATIBLE (or '-D' in your Makefile)
| #include <GL/gl.h>
| -------------------------
... and the choice of preprocessor symbol name, this looks right to me.
Allen
