On Wed, May 03, 2000 at 05:07:21PM -0700, Jon Leech wrote:
|
| It's a dangerous idiom. The app should not be declaring pointers
| whose names are in the 'gl' namespace, period. This problem exists
| completely independently of Linux or the ABI, and we should not cater to
| apps that are doing this.
A point worth considering, though I'm not sure yet that I agree.
Disallowing the use of those names means breaking source-code
compatibility for apps written for systems that possess the prototypes
in gl.h and entry points in libGL.so. It would be nice to minimize
that, or at least reduce the effort required for a fix.
And even if you outlaw the use of gl* names in the app, that still
doesn't solve the problem of the possible absence of PFN*PROC names
from gl.h.
| The GL_<extension_name> symbols are being overloaded. In the past
| they've been used to mean (a) prototypes and enums are defined (b)
| corresponding interfaces are runtime linkable, though perhaps not
| callable.
That's my understanding, too.
| With the advent of the ABI it instead is used to mean (a) interface
| is defined - in some cases via prototypes, in others via typedefs and
| (b) interface is in some fashion accessible at runtime, but not
| necessarily by static linking. ...
I think that's one of the things we're trying to clarify.
| ... Having *two* preprocessor
| symbols/extension is going to produce even more confusion, though.
I didn't think we were proposing two symbols per extension. Just one
symbol that acts as an overall switch to make the semantics of the
per-extension symbols more consistent. (By eliminating the question
of whether the interface is specified by prototypes or typedefs, for
example.)
| In that case, the best we can do is make guarantees in the ABI as to
| which functions are prototyped and which are typedefed. I believe the
| answer should be that all 1.1 or below functions are prototyped only;
| 1.2/ARB_multitexture functions are both prototyped and typedefed, for
| crossplatform portability; all extensions are typedefed only. ...
That sounds good to me.
| ... An
| implementation may provide prototypes for extensions it exports from
| libGL, but calling them is intrinsically unportable. ...
I believe it's important to make that behavior controllable, by using
the mechanism of the overall PORTABLE_SDK switch. It gives app
developers confidence, at compile time, that their use of extensions
is correct.
| Perhaps we should create a utility library, maintained in a central
| location along with glext.h, which lets you do something like:
|
| glextCurrentContext(glext, ctx); // loads function pointers for extensions
| glext->TexImage3DEXT(params); // use function pointer
That's an idea, though if it gets really wide use, we've effectively
reintroduced context-dependent function pointers. :-)
| I can live with the original option B, since it doesn't hurt
| existing applications. But what you're talking about here is not the
| original option B, which had only to do with clause (3) above. The other
| clauses impose new structure on gl.h and glext.h beyond what we've
| discussed in the past. I'm not necessarily opposed to the new structure,
| but we should hash it out a bit.
Yes. It became clear after talking with several people that some
assumed the additional structure was present, and some didn't. An
explicit decision on the matter seems like a good idea.
Allen
