On Thu, 23 Mar 2000, Mark Kilgard wrote:
> 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.
I don't recall a place where we said we would move things OUT
of gl.h - I don't think that's ever intended.
My original understanding was that gl.h would be completely
unchanged compared to a non-oglbase implementation. (with
the possible addition of your GL_HAS_GLEXT thingy.
Extension tokens can be declared in gl.h as they always were
for the local implementation. That's clearly essential for
legacy support - and I don't think we ever intended to remove
them. Rather than that, the intent is simple to DUPLICATE
them (along with every other known extension on the planet)
in glext.h
Refusing to give compile-time indications that glext.h exists
is then a lesser issue than what I think you fear might be the
case.
However, I'd be prepared to concede GL_HAS_GLEXT in order to
avoid the maintenance and specificational evils of (4)...
> 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.
Well, I find it unnecessary - and therefore *slightly* undesirable.
> > 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.
Well, TRUE legacy apps (as in programs that used to run under
Mesa in the days before oglbase) - Yes....but applications
that are ported from some other non-oglbase platform
*recently* - No.
It's likely that no matter what, we'll keep all the old Linux-supported
extensions in libGL.so - that takes care of the legacy problems.
However, what if a brand new program, written just a few weeks ago
on (say) Solaris is brought over to Linux. It might have conditional
compilation for some SUN extension that isn't supported under Linux
but is in glext.h
That's OK so long as libGL.so contains dummy functions for EVERY SINGLE
function thats named in glext.h
As a consequence, you'd have to re-issue a new libGL.so every time
someone added a new SUN extension and tacked it onto the end of
glext.h
Remember that we want OpenGL developers to be able to grab new
copies of glext.h from the www.opengl.org site at any time without
having to wait for their own OpenGL supplier to issue it in an
official release. That's a major design goal because it lets
me write/compile/link code for the very latest 3Dfx extension
- even if my workstation has a year old nVidia card in it
running a six month old Mesa release.
Whilst the OpenSource community (AKA Brian) *might* be able to
keep up by shipping regular libGL.so's to stay in sync with
glext.h changes, I don't think that would go down too well with
the commercial guys. (Actually, I don't think it'll work for
Mesa either - and it's a collosal waste of time).
> The great thing is that if <GL/gl.h> includes <GL/glext.h>, the
> need for GL_HAS_GLEXT goes away.
I'd rather have GL_HAS_GLEXT than update libGL.so on a weekly basis.
> I'm not sure I understand the "failing to link" issue.
Well, it's simply that if you have non-oglbase code that says:
#ifdef GL_EXT_whatever
if ( ...check glGetString(GL_EXTENSIONS)...)
glWhateverEXT () ;
#endif
...then gl.h now includes glext.h, and that defines GL_EXT_whatever,
EVEN IF libGL.so DOESN'T HAVE IT...which means that this application
won't link.
> Options 1, 3, and 5 all create legacy headeaches.
(1) doesn't create legacy problems - it just requires that new oglbase
programs check *externally* for the existance of glext.h rather than
using GL_HAS_GLEXT as you would prefer. Legacy code doesn't ever try
to include glext.h so there are no problems.
I don't think (3) creates legacy problems either. But like (1), it
forces external detection of glext.h for programs that want to be
portable to non-oglbase environments.
> I prefer option 4. Otherwise option 2.
Compromise:
I'll give up option 1 in favor of 2 - but 4 really stinks if you
are in the business of importing code into Linux *and* it's going
to be painful for OpenGL implementors.
The truly great thing about (2) is that it works for XFree86 4.0.0's
Mesa so we won't get 100,000 SuSE 6.4 owners emailing us over the
course of next year.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
