Thanks, Allen, for the levelheaded explanation of the choices. Despite the
fact that it's written in a way that logically leads you to C :-), it did
explain a lot of the issues.
I don't want to come in at this late stage force my opinion on the group
(i.e. I'm not going to vote when I haven't been involved in the discussion.
Rarely do I write OGL code, and I don't write drivers), but I did want lend
my point of view.
> Option A is essentially to leave gl.h as it is, without any provisions
> to include glext.h. [...]
I have to say that the reasons again A in Allen's post do seem a little
weak. The fact that there may be namespace collisions with function pointers
(I'll choose a different name then) and that programs may not link if libGL
doesn't provide the extension have always been there. They are known
quantities which have been around for a long time, and developers know about
them.
With that said the current situation is a little messy. With more and more
sources of OGL arriving under Linux it's becoming more of an issue if people
blindly assume stuff about the implementation running.
> Option B resolves the difficulties with Option A by introducing new
> conventions for the structure of extension declarations in gl.h and
> glext.h. [...]
Option B for me doesn't represent a serious option. Having the default
behaviour as A means that you haven't changed anything. The status quo is
still as it is today. You either make the break, and suffer a little pain
(in the form of broken apps) because you believe it's the right the to do,
or you don't bother and live with the current system.
> Which brings us to Option C. This is the same as Option B, but with
> the sense of the conditional compilation flag reversed [...]
I believe that this is the right way to go. Make the break, suffer the pain,
but let everything heal is a better state. Option C gives a behaviour which
is defined, encorages portable coding, and provides an easy, 'FAQ'able,
solution to the problems associated with compiling old non-portable
applications (i.e. define the compatability symbol).
It seems that the issue boils down to keeping compatability with programs
which call extensions directly (A practice which has always been "on your
own head be it", it may not compile on some systems), or setting a defined
behavior in stone that future programs can rely on.
Paul
P.S. Feel free to ignore everything I say :-)
--
Paul Sargent
mailto: [EMAIL PROTECTED]
