On Fri, Feb 25, 2000 at 10:19:31AM -0700, Brian Paul wrote:
> Mark Kilgard wrote:
> > 4.8. The <GL/gl.h> header must include the preprocessor symbol GL_HAS_GLEXT
> > defined to "1" indicating that a <GL/glext.h> can be expected to exist. The
>
> I'm in favor of this. It would help with portability and doesn't appear
> to have any downsides (if you don't like GL_HAS_GLEXT you can ignore its
> existance).
I could live with it, but note that it's a completely orthogonal
issue to the stated goals of the ABI specification. *By Definition*
glext.h exists in any ABI compliant implementation, just as *by
definition* the headers and libraries live in particular directories. If
you have a non-compliant implementation, then *none* of the guarantees
of the ABI are meaningful. In particular, a non-compliant implementation
can provide glext.h (or not), and can choose to define the preprocessor
symbol (or not) totally independently of each other. Frex: Microsoft is
never going to put this symbol into their gl.h, but glext.h is already
in wide use on Windows.
So basically, I don't think doing this adds any value for a truly
portable (beyond the ABI) app, because such an app will *still* have to
resort to autoconf-like means to determine the availability of this
header.
Jon Leech
SGI
