Disable xterm and XRX builds per default / [Fwd: CVS Update: xc (branch: trunk)]

[Ian Romanick]

Alexander Gottwald wrote:
> On Mon, 24 Jan 2005, Ian Romanick wrote:
> 
>>The net result is that the Darwin and Cygwin builds will need a "fake" 
>>DRI driver that creates this dispatch table.  One nice side-effect of 
>>that is that it will remove the platform-dependent stuff (e.g., work 
>>around GL functions missing in some versions of OS X) from libglx.
> 
> The dispatch table is a mapping GLX call -> OpenGL function? Something
> that is done in g_disptab.c now?

On the server there is a mapping from GLX protocol opcode to GL 
function.  This is done by g_disptab.c and friends.  Right now this 
calls the GL function by name.  In the current setup, the GL function 
"names" live in libGLcore.  Within libGLcore (at least for the Mesa 
software version), there is a pointer to a dispatch table for the 
currently bound context.  The GL functions end up looking something like:

void glBegin( GLenum mode )
{
     dispatch->Begin( mode );
}

They aren't exactly like that, but it's close enough for this discussion.

I'm proposing that the pointer (i.e., dispatch) live in libglx instead 
of libGLcore and that the gl* functions be removed altogether.  This 
matches the way libGL.so / *_dri.so work on the client-side.  At context 
creation time libGLcore be able to modify the dispatch table functions 
to point to whatever it needs.  This could be to functions in Mesa, the 
Apple OpenGL library, or opengl32.dll.  In either case it happens in 
libGLcore and *not* in libglx.

The code that currently lives in the gl* functions would just get folded 
into the __glXDisp_* functions.  In that way the __glXDisp_* functions 
in libglx become like the gl* functions in libGL.so.  If we look at 
libglx / libGLcore as a driver loader and a driver, this makes good sense.

This also moves all of the platform dependent stuff out of libglx.  All 
of the quirky stuff in libglx for determining what GL functions are 
supported on Darwin, for example, moves to libGLcore.  In fact, instead 
of happening at compile time, it could be done at run-time.  The same 
could be done for Cygwin.  You had mentioned that Cygwin could either 
use Mesa or opengl32.dll.  I assume that this selection is made at 
compile time.  Moving forward, this could be done at run-time by loading 
either a Mesa version of libGLcore or an opengl32.dll version. 
Ultimately, the name libGLcore will go away, and it would be either 
mesasw_dri.so or opengl32_dri.so on Cygwin.

My intention is to get this working on Linux first, then worry about 
getting it working on the other platforms.  And like I said before, this 
is still a long way from seeing fruit.