[EMAIL PROTECTED] wrote:
>
> Reduce the problem to a two-way choice. Since Option B
> subsumes Option A, we'll go with B vs. C.
Jon's original "A" option:
A) Do nothing (current oglbase proposal). glext.h must always be
#included explicitly by the application.
Allen, I don't believe that your new, revised description of "B"
subsumes "A" at all. In fact, it directly contradicts the original
"A" that we all voted for by explicitly #include'ing glext.h in one
case, and making the behavior wishy-washy and undefined in the default
case. This makes it much closer to a subsumption of the origianl "C"
option, and nothing like "A" at all. Therefore it's utterly improper
to summarily reduce the vote to these two options.
In Jon's original vote, the (A,B,C) options for #2 simply boiled down
to whether glext.h was automatically included or not. No reference to
making function prototypes part of glext.h was made. However, it seems
clear that, due to the existance of glXGetProcAddress, the OGLBASE
compliant default should be to typedef the extension functions, but not
prototype them (as in your new "C" option).
In short, it seems like if you want to meld the two issues, and you want
your new "B" option to actually subsume the original "A" proposal, it
needs to be redefined something like this:
B. Default case: glext.h defines only constants and datatypes needed
for the extensions (including typedefs of any extension functions).
Extension function prototypes are explicitly not contained in glext.h.
Also, glext.h is explicitly not #included by gl.h, and thus must be
explicitly #included by the compliant application if extensions are
desired. This is defined as the "new" OGLBASE behavior.
Non-default case: If the preprocessor symbol GL_OGLBASE_INCOMPATIBLE
is defined, the implementation is free to do whatever it used to do
in order to maintain backwards compatibility with legacy applications.
i.e. gl.h may include glext.h, which may contain function prototypes.
and "C" should then be defined as:
C. This is the same as "B", except that the sense of the preprocessor
symbol (and thus the default behavior) is reversed. So the new
preprocessor symbol would be GL_OGLBASE_COMPATIBLE, which would enable
the "new" OGLBASE behavior, but the default would be to remain backwards
compatible with previous versions.
Given these modifications, I'll vote for "B". Otherwise, I find both options
rather repugnant (although "C" seems slightly less repugnant).
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]
HP Technical Solutions Laboratory
- i n v e n t -
