On Mon, Mar 20, 2000 at 03:20:18PM -0600, Stephen J Baker wrote:
> On Fri, 17 Mar 2000, Jon Leech wrote:
>
> > On Fri, Mar 17, 2000 at 09:51:13PM -0800, Mark Kilgard wrote:
> > > Without GL_HAS_GLEXT, it is impossible to portably know if <GL/glext.h>
> > > can be included without a compile-time error.
> >
> > Au contraire; the symbol has no utility for portable source code.
> > For an oglbase environment, it is not needed. For any other environment
> > (read: Windows, MacOS, vendor UNIX), it is highly likely that the symbol
> > will not ever be put in gl.h, *just as no other guarantees of oglbase
> > are meaningful for such an environment*.
>
> ...and on a Linux/UNIX box, you can always use an external configuration tool
> like autoconf/automake to decide whether the glext.h file *actually* exists and
> provide a '-D' directive where needed. That's far better than defining a symbol
> in gl.h that could be lying to you if some dumb user either copied gl.h from
> another machine/directory or something.
Sorry if I'm sounding like a broken record, but GL_HAS_GLEXT simply
addresses the wrong problem. If you aren't building in an oglbase
environment, the application's own configuration process *must* provide
this information. If you are building in an oglbase environment, it's
giving too *little* information; knowing that glext.h exists does not let
you know that anything else mandated by oglbase is true.
Nobody expects stdio.h to e.g. #define STDIO_HAS_VARARGS_H, gl.h to
#define GL_HAS_GLX_H, etc. Determining that sort of stuff has always
been a function of either the compilation environment, which
intrinsically defines OS or CPU or standards-compatibility symbols, or
of the application's own configuration process, which determines what is
*actually* available at build time - and it's not like autoconf is an
immature technology! This nonsense of keeping a dozen different
Makefiles around for every different platform a package builds on
properly belongs to the dark ages of the early 80s.
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.
Jon
