On Mon, 8 May 2000 [EMAIL PROTECTED] wrote:
> | 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.
Yep - that's pretty typical.
> 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). Programs that use dlsym to do this should
still be happy.
> 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.
#ifdef _linux_
#include <GL/glext.h>
#else
#include "my_own_PFN_functions.h"
#endif
...or just leave out glext.h
This is a minor annoyance - but compared to the other things you
have to do for ABI compliance, it's no big deal.
> 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.
But for existing programs, there is no change! No change at all...how
can that possibly be incompatible?
> 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.)
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?).
The nVidia OpenGL for Linux doesn't ship a gl.h - I don't
think *anyone* will be using the SGI reference implementation gl.h
yet - and even if they do, they are 'gurus' of one kind or another
and can deal with it.
> 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.
Except that this is the case currently. Programs *do* happily compile
with either gl.h that currently exists.
> Options B and C could make that guarantee, though.
Indeed.
> | 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?
Well, normal C programming style says that each header file should include
everything it needs so that there are no ugly order-dependencies. Hence
even if we decreed that gl.h *and* glext.h should be included into valid
ABI programs, any reasonable person would want to include gl.h into glext.h
just for 'cleanliness' sake since glext.h needs the definitions of GLfloat
et al.
> ... the choice of preprocessor symbol name ...
Yep - I just picked a name out of the air - I'm sure a very
short discussion will get us the 'right' name once we agree
on the principals.
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
