On Mon, 27 Nov 2000, Sven Goethel wrote:
> Aehem, well, but how about splitting the Mesa distribution from:
> MesaLib & MesaDemos
> to:
> MesaLib & (MesaSGIGLU || MesaGLU) & MesaDemos
>
> where, of course, the MesaSGIGLU is preferred ..
If there are going to be ugly issues with which C++ runtime library
SGI-GLU pulls-in/requires then I think it's vital from an application
support perspective to minimise the number of varients there can
be out there. I would not want to see (say) Debian and RedHat shipping
the SGI version of GLU with SuSE and Corel shipping GLU-classic.
I'd also oppose splitting GLU off from Mesa's main download because
that will result in lots of end-users installing "Mesa" and yet having
no valid GLU implementation because they failed to download/install it.
Supporting OpenGL applications under Linux is hard enough as it is -
look at the mail archives for an active OpenGL application (TuxRacer
for example) and you'll see that at least 95% of the posts are OpenGL
installation problems of one kind or another. That consumes an insane
amount of people's time - PLEASE, let's not make it any harder.
IMHO, 99% of widely distributed OpenGL apps for Linux will not be
using the problematic functions in GLU-classic - because those programs
were almost certainly developed using that library and either don't use
the broken functions or have work-arounds that work OK. Hence most
existing applications will get no benefit from SGI-GLU. In any case,
the kinds of applications that need things like tesselators and spline
patches tend not to be games - more often they are things like scientific
visualisers and custom applications which are not widely circulated.
Hence, I suggest that until the g++ standard library stuff settles
A
down, we avoid making SGI-GLU the default. I think the Mesa documentation
should point out that we *WILL* make the transition - but not yet - and
advise people who experience problems with GLU-classic to switch over
immediately. Meanwhile I think we should continue to ship GLU-classic
by default.
---
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@xxxxxxxx http://www.link.com
Home: sjbaker1@xxxxxxxxxxx http://web2.airmail.net/sjbaker1
|