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?
As a slight digression, I just called Dale Scheetz, who is one of
the principals of LSB, and asked him how LSB handles these configuration
issues (I was hoping to follow their naming conventions).
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.
> 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.
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.
In any event, people are not going to depend on ABI compliant source
or binaries until (a) the ABI is complete and (b) it's widely available.
I don't think the fraction of SuSE users who choose to upgrade in the
near future will count as "widely available".
> > 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.
Jon Leech
SGI
