Re: [Freeglut-developer] What are we doing?

[Braden M. <br...@en...>]

Quoting Steve Baker <sjb...@ai...>:

> It doesn't hurt to modestly enhance freeglut - there are some missing
> features
> of GLUT that are so important that their absence is essentially a bug.
> 
> Perhaps we can resolve this issue properly by making build options
> to install EITHER as GL/freeglut.h & lib/libfreeglut.so *OR* as GL/glut.h and
> lib/libglut.so.   Let the person doing the installation decide whether
> they want *just* freeglut (running as GLUT) or to have both GLUT and
> freeglut installed at the same time.

IMO, such schizophrenia does more harm than good, as you complicate life for
packages that depend on glut, but would like to work with freeglut as well. Such
packages may:

 * ignore (or be oblivious to) the fact that two freeglut installation modes
   are possible.
 * realize that the two freeglut installation modes are possible, but botch
   modulation between them in some way.

The first is very likely to happen. The second is a virtual certainty, unless
you provide some *easy* means of letting users Get It Right.

This is a lot of trouble for something that users could resolve on their own by
installing to different prefixes.

***

Maybe I should start a new thread for this, but it's somewhat related. I
previously tossed out the idea of moving the non-glut parts of freeglut to a
different library, but prompty backpedaled on the notion. I've thought about it
a bit more, and I think it might be a good idea for this reason: doing so should
allow you to freeze (usefully) the library version number of libglut, while
allowing the extension library to continue to evolve as necessary (with
corresponding useful changes to its library version number).

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>