In your message of 23 March 2000 you write:
> On Wed, 22 Mar 2000, Michael Gold wrote:
>
> > > All future Linux/OpenGL/Mesa development should use
> > > glXGetProcAddressARB.
> > > But in the mean time, these three items will help ensure backward
> > > compatibility with the existing applications, both at compile
> > > and runtime.
> >
> > From your description then it sounds like the scenario Steve describes is
> > not (or less) likely to be a problem in practice. If the prototypes are
> > defined, there will be no compile errors, and if the EXT entry points exist
> > in the dso, there should not be link problems either. Do you agree?
>
> No. Mesa is only one of the OpenGL implementations for Linux - there
> are others. Will there be similar entrypoints in the nVidia/SGI OpenGL?
> How about XiG's implementation?
We went with a pretty much the same Solution as Mesa. Our core
libGL.so defines all entry points for extensions that are supported by
our drivers (i.e. X-Server). gl.h therefor has all the tokens and
function entry points declared. To be forward compatible with
glext.h/glGetProcAddressARB(), gl.h also declares the functions
pointers for those extensions. gl.h does NOT include glext.h, as it
would break old applications, and would make porting from other
platforms uneccesary difficult. glext.h include gl.h, and only adds
the extension defines/declarations for extensions not already covered
by gl.h. This way things are always consistent.
> This is a spec for a standard - and if adding all those entrypoints
> into every libGL.so (and updating them regularly) is to be a part of
> the specification - then we need to write it in.
This would be a very serious maintaince problem. If there is a set of
expected base extensions that should be there for historical reasons,
then this is ok, but if it gets to wild, it will be a problem.
> The spec should also say what happens if you (illegally) call
> one of those stubs - perhaps it should be a GL Error kind of
> a thing - perhaps it should just silently do nothing - or
> maybe we want to say it's "undefined" (ie you get a core
> dump). I don't care which we say - but if we do go this
> way, we need to say something.
>
> We keep talking about "legacy apps" in this context - and I'd
> like to point out that it's NOT just older code that'll cause
> a one-time hit that we can somehow overcome by judicious
> placement of dummy routines into libGL.so
I think that this goes back to the original reasoning why there is a
glGetProcAddressARB() in the first place. Extension functions should
never be used directly on a oglbase compliant system, but ALWAYS
retrieved throu glGetProcAddressARB(). Jon also noted very early on,
that there are a few extensions that are really considered standard,
and are used by a lot of legacy apps, and in fact have made it already
into the core 1.2 standard. Those should be at least there as
functions in libGL.so, in order not to break things. The oglbase still
doesn't really address this part.
> Anyway, if all Linux OpenGL's will commit to adding those
> entrypoints into their libGL.so's by the time oglbase
> becomes law - then I have a much smaller objection to
> including glext.h into gl.h
The problem is portability. There are multiple libGL.so libraries out
there, and keeping them all in sync will be impossible. This places a
big burden on both the application developers, as well as the
maintainers of libGL.so. Having stubs for every possible extension is
just not really feasable.
> Just out of interest, what's the objection to doing the
> opposite and including gl.h into glext.h ? It seems to
> me that this would be as good a solution as the reverse
> from the point of saving our children from the terrible
> evils of needing two headers - and yet preserve the
> ability of existing legal OpenGL programs to work
> unmolested.
That is what we are actually doing. But more for the reason that
glext.h needs always types from gl.h. Especially since some extensions
are defined in gl.h.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
