Here's my dull roar, and why I prefer (b) or (c) over (a).
Thomas said something good on Friday - if some symbol is defined which
indicates that glext.h should be included from gl.h, it also suggests that
static prototypes should _not_ be included in gl.h. Hence an application
which defines GL_OGLBASE_EXTENSIONS, or doesn't define
GL_NO_OGLBASE_EXTENSIONS, depending on whether (b) or (c) won the vote,
would be protected from accidentally linking to static extension entry
points and thus sacrificing the portability which was sought by porting to
the oglbase mechanism in the first place. That is, a warning would be
printed during the compilation phase because no prototype exists for the
function.
The flaw with option (a) is that no such compile-time protection exists, and
a developer might inadvertently ship a binary which uses static extension
entry points.
I'm surprised that (a) has garnered as much support in the early voting as
it has, since I expect that (b) would be acceptable to anyone who hates (c),
e.g. Steve. My choices, ranked in order of preference, are c, b, a.
-- Michael
> -----Original Message-----
> From: Brian Paul [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 27, 2000 4:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [oglbase-discuss] VOTE: glext.h/preprocessor handling
>
>
> Jon Leech wrote:
>
> > Please try to keep the politicing down to a dull roar while the
> > voting is going on (e.g. don't accompany the vote with further
> > arguments, and don't use other people's votes as a
> launchpad for more
> > arguments).
>
> I don't want to persuade anyone's vote but I thought I'd explain why I
> voted as I did for option A since it's different that what I expressed
> last week:
>
> 1. Existing OpenGL code will work as-is.
>
> 2. If you're going to write the app code to use a new
> extension then adding
> the code to include "glext.h" is a trivial part of that work.
>
> 3. You have the option of wrapping the #include "glext.h"
> directive inside
> a preprocessor test of your own so it can be a Makefile or
> autoconfigure-
> controlled option.
>
> 4. People could include a copy of glext.h with their source code. It
> might be out of date with respect to the latest version of
> glext.h but it
> would have the extension definitions that they care about. This could
> prevent compile errors but might result in link-time errors
> (ala Steve Baker's
> situation).
>
> 5. This is basically what's required on Windows. Microsoft
> isn't going to
> update their gl.h with new preprocessor symbols anytime soon.
>
> -Brian
>
