GLE Build Notes & General Info

Background and Overview

GLE is known to run on UNIX(r) and UNIX-like operating systems such as Linux, AIX, IRIX, Ultrix and HPUX with OpenGL or Mesa. GLE is also known to run on OS/2 Warp.

A spec file is included for automatically building RedHat RPM's.

Build Notes

To build the library, simply type configure at the command line to set things up for your CPU & operating system. Then run make to compile. Finally, cd to the examples directory, and run the shell script rundemo to launch each of the demos in order (from most basic, to advanced).

You may find the following configure flags useful:

--enable-lenient-tess

If you have a tesselator that is happy with anything, including degenerate points, collinear segments, etc. then define this. Otherwise, don't specify this flag. Setting this flag provides a minor performance improvement. I believe that the stock SGI tesselator is "lenient", despite explicit disclaimers in the documentation. (circa 1995). Early versions of the MesaGL tesselator are not at all forgiving of degenerate points. This resulted in frequent crashes and/or hangs. (circa 1997-2000). Recent versions (as of 2001) seem to work fine. If you have an old version of MesaGL, do not set --enable-lenient-tess

--disable-auto-texture

Disable texture mapping code. Disabling texture mapping may provide a very minor performance improvement.

--enable-irisgl

Compile for old IrisGL/GL-3.2 API. This used to work, but hasn't been tested in a long time.

--enable-debug

Will compile sources so printf routines will be called instead of OpenGL routines. Warning: this will generate a *lot* of output!

If you have difficulties... here are some notes:

IBM AIX, SGI Irix, HP and DEC Systems

There are no known compile or run time problems. If you have difficulty making on these systems, make sure that OpenGL and GLUT are present. (Note: the new automake/autoconf build process has *not* been tested on these systems.)

Linux Systems

Older MesaGL tesselator was prone to hangs and crashes. Recent (2001) versions seem to do just fine. There are currently no other known compile or runtime problems.

Windows NT/2000 and Windows 95/98

GLE will compile & run on these Microsoft systems under several different development environments. The subdirectory ms-visual-c contains project files. The README contains additional information.

Macintosh OS version 9

GLE has been reported to compile & run on this Apple operating system using the CodeWarrier development environment, once some 'standard' modifications are made. (??)

GL and OpenGL Libraries

The tubing and extrusion library can be compiled for GL 3.2 or for OpenGL. By default, the Makefile are configured for OpenGL. (Warning: the library has NOT been run on GL 3.2 in years, and so might be broken in minor ways. With tweaking, though it should work.)

Obtaining the GL, OpenGL and GLUT libraries

OpenGL is available on most UNIX(R) workstations, as well as OS/2(R) and Windows NT. Contact your workstation vendor for more information or visit the OpenGL Web Site (See also SGI's OpenGL site). GLE also works with Mesa, a public-domain OpenGL-like API. Mesa can be found at http://www.mesa3d.org/

The demos require that the GLUT windowing and utility library be installed. GLUT can be obtained at http://reality.sgi.com/opengl/glut3/

GLUT Libraries

The demos require the GLUT library and headers to be installed.

Compile time warnings

You may see some compile time warnings. Ignore these. These occur because not all compilers correctly handle doubly-index subscripts, and so the code does some funny business to get around this. To the best of my knowledge, the code still executes correctly despite these warnings. Note, however, that my efforts to eliminate these warning may result in code that old compilers will not be able to compile, or will compile but not execute correctly.

(In my humble opinion, the way in which the C/C++ language handles doubly, triply, etc. subscripted arrays is fundamentally broken. The syntax is not self-consistent. Many important constructs are undefined by ANSI-C (and C++). In the good old days, when most compilers were broken in this area anyway, you could happily work around this with single-index arrays and fancy address calculation. Now that compilers have been fixed, and, thanks to C++, strict-type-checking is all the rage, the fundamental short-comings of C/C++ in this area start becoming horribly apparent. To put it another way, I agonized over how subscripting should be handled, and what, if any new types needed to be introduced. Sadly, I was unable to design code that compiled on most compilers, AND not introduce new types, AND avoid strict-typechecking warning messages. Sadly, the result is a horrible mess. )