Re: READ THIS; Debian XFree86 4.0.1 mini-FAQ
On Sun, Sep 24, 2000 at 10:23:55PM +0200, Marcelo E. Magallon wrote:
> >> Joshua Shagam <joshagam@cs.nmsu.edu> writes:
>
> > I see no reason that libGLU *as it stands now* needs to be bundled
> > with any specific OpenGL implementation or driver.
>
> It's just what the Linux OGL base decided. Playing along is the most
> sensible thing to do as incompatibilities between different OGL
> implementations has been one of the largest sources of headaches in
> the past (glXCreatePixmapMESA anyone?)
Well, glXCreatePixmapMESA is clearly a divergence from the OpenGL spec.
That's also part of glX, not of GLU (which doesn't even make calls to glX).
> > (Myself, I only use one libGLU call in my entire 3D engine, and
> > even that could be easily replaced with a raw OpenGL call if I
> > weren't so lazy.)
>
> That very one call is probably the reason some large ammount of
> programs link against libGLU. I guess a rather small ammout of those
> programs use the mipmap functions, and a even smaller use the
> tessellation or nurbs functions.
Oh, my bad, two calls. :) (gluPerspective is the one I was thinking of - I
forgot about gluBuildMipmaps.)
> > Basically, I think there should just be one libGLU which is
> > packaged on its own (for now), and any program which uses GLU
> > should just have it as a requirement.
>
> The OGL base specifies you should provide both. It is true that you
> can mix and match any libGL (xlibmesa3, NVIDIA's, ...) with any
> libGLU, but IMO it's cleaner if the vendor provides both. Saying
> it's ok to do otherwise leads you a step closer to the current
> situation with the NVIDIA drivers, where you don't get a proper
> development environment from them.
>
> You could argue that it could be possible to split libGLU into it's
> own package. Technically there's nothing wrong with that, except
> that every package providing libgl would have to have a 'Depends:
> libglu' introduced (since the one package providing libgl had libGLU
> in it) and this gratutiously breaks the possibility of installing
> woody compiled packages on a potato system (because of other factors
> this probably has already happened, but introducing yet another one
> is not nice).
Good point, and it's not like libGLU is very big to begin with. What's the
current rationale for XFree 4's libGL not including libGLU, then? I guess
in all the discussion of it needing to go in, I've lost track of why it
isn't been in there to begin with...
--
Joshua Shagam /"\ ASCII Ribbon Campaign
joshagam@cs.nmsu.edu \ / No HTML/RTF in email
www.cs.nmsu.edu/~joshagam X No Word docs in email
/ \ Respect for open standards
Reply to: