On Thu, 23 Mar 2000, Jon Leech wrote:
> On Thu, Mar 23, 2000 at 03:41:40PM -0600, Stephen J Baker wrote:
> > On Thu, 23 Mar 2000, Jon Leech wrote:
> > I also agree that OGLBASE_VERSION_1_0 is nicer than GL_HAS_GLEXT (although
> > it shouldn't have an O at the beginning because that pollutes namespace
> > - and the work 'BASE' has been dropped from our title...hence perhaps:
> >
> > GL_ABI_VERSION_1_0
> >
> > ...would be better).
>
> Point, but there should be something denoting whose ABI it is.
> Also I'm not entirely comfortable throwing in random GL prefixes
> when there are no GL namespace rules covering this case.
> Maybe GL_LINUX_ABI_VERSION_1_0?
I think choosing the string LINUX would be A Bad Thing because
we would really like this standard to be adopted by other UNIXen
and that'll be a harder sell if we embed LINUX in the name. Something
more OS-neutral is needed IMHO.
I'd hate to have to write code that said:
#if defined(GL_LINUX_ABI_VERSION_1_0)|| defined(GL_BSD_ABI_VERSION_1_0) || \
defined(GL_IRIX_ABI_VERSION_1_0) || defined(GL_SOLARIS_ABI_VERSION_1_0) || \
defined(GL_BEOS_ABI_VERSION_1_0) || defined(GL_MACOS_ABI_VERSION_1_0)
#include <GL/glext.h>
#endif
> Answer: apparently LSB doesn't address this. Whether or not to build
> for an LSB environment is entirely in the application's hands. There are
> check programs that after the build will examine a binary and say
> whether or not it's LSB compliant, or that will examine the system and
> state whether or not it's LSB compliant (I think this is to be used when
> installing an LSB-compliant app). But nothing at the granularity we're
> discussing here.
I'd be happy to go with that - autoconf makes that kind of thing very easy
and autoconf is what 95% of Linux programs use....but we are trying to
compromise with Mark's position in order to get on with our lives here.
> > However, there is one thing to be said for sticking with GL_HAS_GLEXT
> > (ugly though it is) and that is that it's already in the Mesa header
> > that shipped with XFree86 4.0.0 - so by changing it, we delay by one
> > whole XFree release the time at which we finally see an ABI compliant Mesa -
> > and there ends up being a bunch of SuSE 6.4 users with halfway compliant
> > code that could end up biting us for the next year or so.
>
> There is no ABI yet, so XFree86 4.0 cannot possibly be compliant.
Well, it seems to be compliant with what we have written so far. If we
can get over this point (and since we are WELL past the end of the public
comment period) then we can declare XFree86 4.0 compliant and get outta
here.
> I'm sorry that the 4.0 deadline came before we finished this, but
> just because that happened doesn't mean that any particular
> implementation gets to unilaterally dictate. That is not how a standards
> process works, and it is entirely too short-term a view of things.
I understand that - but if the issue is a tiny one (which this is) then
we can save perhaps a year in finally getting rid of non-compliant systems
by accepting XFree 4 as compliant. (I presume this is the only thing on
which it would fail - right?)
If this was a BIG issue (like how glGetProcAddress works or something) then
I'd agree that we have to get it utterly right before committing - but the
choice of a name for a token that most of us don't even want to use...I don't
think that's worth an extra year (maybe) of lingering incompatibility.
> > > I don't have any fundamental objection to mandating that glext.h be
> > > #included in an oglbase compliant gl.h, for that matter.
> >
> > But it breaks existing, *legal*, well-written OpenGL programs!
> > Lots of them! I can't believe you'd accept that.
>
> Point. The thread has been so hot and heavy that I missed your
> observation on that.
You *are* kidding - right? :-)
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
