On Thu, Mar 23, 2000 at 12:57:11PM -0800, Mark Kilgard wrote:
> As Brian, Thomas, and myself has been arguing, more weight needs
> to be given to legacy support than has been given so far.
>
> I note that the people who favor giving more weight to legacy
> issues are the people who have have substantial experience with
> legacy issues and are likely more in tune with the email and
> hassles creates by not properly addressing legacy issues for
> popular open source projects.
I don't note that at all. I note that there is a misunderstanding of
what the oglbase spec actually says, and a chain of invalid assumptions
built atop that misunderstanding.
> I think the single mistake so far is the attempt to
> invent a new OpenGL oglbase standard without any real regard for
> the legacy issues. Moving existing defines and prototypes out
> of <GL/gl.h> is the core mistake. This mistake is compounded if
> the standard refuses to give any compile-time indication of
> when these declarations have moved.
(also a similar comment a few days earlier):
MJK 21 Mar 2000:
> 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>.
The draft spec DOES NOT mandate "Moving existing defines and
prototypes out of <GL/gl.h>". I'm mystified as to where this assertion
came from. What is DOES say is simply:
"4.6. Non-ARB extensions are in general to be defined in glext.h. If
they are also defined in one of the other required headers, this
must be done conditionally so that multiple definition problems
don't occur."
I fully expected in writing this that existing implementations would
continue to provide the interfaces they statically export in gl.h; it
would be idiotic to do otherwise precisely because it creates problems,
but there IS NO LEGACY ISSUE if this is done. There will be some slight
overlap in the two header files; that's not an issue if the
extension-specific preprocessor symbols are used to properly protect
prototype declarations.
> This has been what I've been arguing for because it was the smallest
> change to the current proposal that allows highly-portable OpenGL
> code to at least determine at compile-time whether the Linux oglbase
> standard is supported by the compile-time OpenGL implementation.
That isn't what you have been arguing for as I've been reading it:
MJK 24 Feb 2000:
> I have one concern about <GL/glext.h>.
>
> I'd like some heuristic for determining when <GL/glext.h> can be
> expected to exist.
MJK 1 Mar 2000:
> While the focus of oglbase-discuss is for Linux installations, we
> shouldn't lose sight of the fact that other OpenGL development
> environments are likely to follow any <GL/glext.h> standard established
> by oglbase-discuss. The simple portable GL_HAS_GLEXT mechanism
> seems simple enough and does not depend on autoconf.
MJK 17 Mar 2000:
> Without GL_HAS_GLEXT, it is impossible to portably know if <GL/glext.h>
> can be included without a compile-time error.
MJK 21 Mar 2000:
> 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 agree that the much broader issue of determining whether or not an
oglbase-compliant build environment is present is worth knowing. I am
even (somewhat reluctantly, but in the interests of resolving this)
willing to agree that oglbase should mandate some preprocessor symbol in
gl.h, such as OGLBASE_VERSION_1_0, to indicate this.
But that's distinct from the narrower issue you initially raised, of
whether or not glext.h exists in any particular environment. It would be
fatal to assume that because glext.h exists, so does everything else in
the compile-time oglbase environment - glext.h is by design and by
existing practice already used in non-oglbase environments.
I don't have any fundamental objection to mandating that glext.h be
#included in an oglbase compliant gl.h, for that matter. Doing so
doesn't help portable code, which will still have to explicitly #include
glext.h in other environments, but that's OK. Truly portable code has to
do lots of environment-specific stuff.
BTW, you could easily distribute a copy of glext.h with your simple
GLUT example programs, instead of trying to figure out whether a version
exists in the system environment - just as most truly portable code is
likely to do eventually IMO.
> Options 1, 3, and 5 all create legacy headeaches.
Not unless the author of gl.h buys into the notion of removing
existing extension interfaces in the process of making it oglbase
compliant.
Jon Leech
SGI
