oglbase-discuss,
Steve Baker has put the options out on the table. Thanks, Steve.
> So - how do we decide this?
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 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.
> 2) Require oglbase apps to #include both gl.h and glext.h
> gl.h does NOT include glext.h
> gl.h defines the symbol GL_HAS_GLEXT
> glext.h may or may not include gl.h (it needs GLint,etc
> so it probably should)
>
> * This is what Mesa/XFree86 4.0.0 assumes.
> * Dunno if XiG defines the GL_HAS_GLEXT token yet.
> * It's easy to tell if this is an oglbase
> compliant OpenGL.
> * Legacy code compiles OK.
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.
I had expected this to be pretty uncontroversial, but I clearly
expected wrong.
> 4) Require oglbase apps to #include only gl.h
> gl.h must include glext.h
> libGL.so must contain 'enough' dummy functions
> for extensions that it does not support to enable
> legacy and newly ported applications to link.
>
> * This won't work for either Mesa/XFree86 OR XiG
> right now since neither includes glext.h from gl.h.
> * There are 'issues' about keeping
> libGL.so up to date and consistant.
> * There is still a possiblity of a newly ported
> program failing to link - but most legacy apps
> should be OK if we are careful with libGL.so.
I believe that is actually the option that best supports
legacy apps.
The great thing is that if <GL/gl.h> includes <GL/glext.h>, the
need for GL_HAS_GLEXT goes away.
This option *will* work with today and yesterday's Mesa/XFree86 OR
XiG because they will be using an old <GL/gl.h> that has all the
extension prototypes and defines. With a new <GL/gl.h>, the
extension declarations will likewise be found because of the
automatic inclusion of <GL/glext.h> from <GL/gl.h>.
I agree that there are issues for legacy maintence, but these
are issues (that in the case of Mesa) Brian is clearly aware of
and sounds quite willing to shoulder.
I'm not sure I understand the "failing to link" issue.
Options 1, 3, and 5 all create legacy headeaches.
I prefer option 4. Otherwise option 2.
- Mark
