[GRASS5] Darwin Pre1 NVIZ

[Glynn Clements]

Eric G. Miller wrote:

> > Are you actually using r3.showdspf.openGL (from GMSL/g3d)? AFAIK, this
> > is the only program which actually requires libGLwM. As it currently
> > has outstanding bugs, it isn't in the 5.0.0 release branch in CVS.
> > 
> > Also, its documentation specifically refers to using Mesa's libGLw
> > (from the widgets-sgi directory) rather than libMesaGLwM (from
> > widgets-mesa).
> > 
> > I don't want to change configure to accept libMesaGLwM in place of
> > libGLwM unless it's known to work.
> > 
> > If GMSL/g3d isn't going to make it into the release, we may as well
> > just remove the GLw checks altogether; otherwise they just confuse
> > people.
> 
> I might add, the widgets should have appropriate symlinks. Like:
> 
> libGLwM.a --> libMesaGLwM.a

Note that Mesa includes both libGLw.a (widgets-sgi) and
libMesaGLw[M].a (widgets-mesa). The README for widgets-mesa says:

  * Provide a GLwDrawingArea widget which is 100%ly compatible with
  SGI's widget.  Applications should port over with (almost) no
  changes to the source code.

It's the "almost" which concerned me.

However, the original SGI version only has a libGLw.a. The Mesa
version used to be this way, but it was changed (by me) to put the
Motif version into a separate library (otherwise you had to link
against libXm even if you only used the non-Motif widget).

XFree86 4.0.* again includes both Motif and non-Motif versions in its
version of libGLw.a. However, even if you add a libGLwM.a symlink,
configure won't detect it because, in that version,
GLwCreateMDrawingArea() is a macro which expands to either
GLwCreateM1DrawingArea() or GLwCreateM2DrawingArea() depending upon
whether XmVERSION is 1 or 2.

Anyway, all of this is moot unless g3d finds its way back into the
source tree.

So, should I get rid of the GLw checks altogether? Or is g3d's absence
likely to be only temporary?

-- 
Glynn Clements <glynn.clements at virgin.net>