Jon,
> I might have less of an issue with providing something like an
> OGLBASE_VERSION_1_0 symbol to indicate that (as far as the header file
> is concerned, anyway) that environment is available. Headers cannot know
> about the entire environment and still may easily be lying, but at least
> it would try to give the application more broadly useful hints.
In that case let's mandate the symbol OGLBASE_VERSION_1_0 in <GL/gl.h> and
be done with it. I would certainly prefer something such as GL_HAS_GLEXT
that specifically means that <GL/glext.h> can be safely included and
I will try again to make the case for it.
I don't really understand why you object so strongly to GL_HAS_GLEXT.
It seems a simple solution to something that clearly will be a problem
for developers seeking highly portable source code. I'm not the only
one who has expressed the strong need and desire for this simple
mechanism. Brian Paul was nice enough to re-iterate his support for the
idea.
Please appreciate that there is a real need to distribute short,
self-contained OpenGL example code demonstrating new extensions to
OpenGL programmers at large. Such examples do NOT have "autoconf"
or other build environments. Such examples are unlikely to even
include Makefiles because of the difficulty supplying truly
portable Makefiles. These examples often go to novice programmers
that often don't fully understand the nature of their development
environment (yes, that's unfortunate, but it is reality of novice users).
I know because I'm the author of a lot of such programs. Unfortunately,
if the OpenGL Application Binary Interface for Linux defines OpenGL
extensions in the new <GL/glext.h> instead of the old convention of
putting such defines in <GL/gl.h>, such example programs can't reliably
(meaning without compile-time errors) find the extension defines and
prototypes the example may need.
The problem with the OpenGL Application Binary Interface for Linux
standard as it stands now is that it does not simply add a new header
with new defines and prototypes. It MOVES OpenGL extension defines and
prototypes from the existing <GL/gl.h> header to a new header <GL/glext.h>.
In general, I think this is a fine idea (it cleans up the name space, makes
<GL/gl.h> a more defined stable file, etc), but there just needs to be some
indication in the new <GL/gl.h> files that this new convention is being
followed for the compile-time benefit of highly portable source files. This
is the purpose of GL_HAS_GLEXT.
> Nobody expects stdio.h to e.g. #define STDIO_HAS_VARARGS_H
Yes, but that's because no one expects to find defines
and prototypes that were once in a standard header moved to a new
header. New C header files usually evolve without changing the
contents of old existing header files.
Again I certainly understand the rationale and desire to keep a <GL/glext.h>
with extension defines and prototypes apart from the more stable
<GL/gl.h>. It's a good thing. But since it is so easy to do, let's
add a single simple convention that helps programs correctly compile
on both old environments and new environments.
The problems created are not at all hypothetical. Novice users that want
to learn about OpenGL extensions find that they often can't build the
simple examples that they find on the Internet from books, articles,
and distributions such as GLUT. It creates an unnecessary barrier to
these new users learning OpenGL. A convetion such as GL_HAS_GLEXT
can eliminate one signficicant source of compilation difficulties
for these new users wanting to learn OpenGL.
I *fully* appreciate that problem is not narrowly a problem with
the OpenGL Application Binary Interface for Linux but by adopting
this extremely simple convention, I believe we can greatly increase
the overall portability of OpenGL example programs.
I *fully* appreciate that "autoconf" and similar program configuration
tools offer another solution to the problem. That's great, but it
should not preclude a much simpler, very inexpensive solution (I mean
it adds a single line to <GL/gl.h> after all).
Brian Paul and I and others continue to consider GL_HAS_GLEXT to be a
very reasonable solution, but OGLBASE_VERSION_1_0 is also acceptable.
OGLBASE_VERSION_1_0 suffers from the potential for misuse along the
lines of __ANSI_C__ because of the vagueness of what it means, so
GL_HAS_GLEXT still seems more appropriate. The nice thing about
GL_HAS_GLEXT is that other environments can also adopt this convention
instead of inappropriately defining OGLBASE_VERSION_1_0.
- Mark
