Re: XDPS compile problem

[Frederic De Jaeger]

AF> Nope. I originally named the functions without an 'X' because those
AF> methods aren't supposed to be X-Windows specific (although technically
AF> they are currently). I don't know how the xdps methods got changed, but
AF> they should also be without the X (except they should call the correct
AF> DPS/X function with the X).

AF> I don't think there is any point in changing the name since almost
AF> always there is no need to actually use these functions within GNUstep -
AF> they're almost always used internally.

I understand your point of view. Thus there are less things to change.
(remove the X in NSDPSContextOps.m).
There is still a little problem. Applications don't link at this
moment because of SharedX/XGBitmapImageRep.m 
the problem is here :

.
.
.
#ifdef XDPS_BACKEND_LIBRARY
#define   XGContext NSDPSContext
#include "gnustep/xdps/NSDPSContextWindow.h"
#else
#include <gnustep/xgps/XGContext.h>
#endif
.
.
.

When the xdps backend is compiling, it includes
xdps/NSDPSContextWindow.h that does not define DPScurrentgcdrawable.
On the contrary, xgps/XGContext.h  includes AppKit/AppKit.h that (I
suppose) should include AppKit/DPSoperators.h that defines
DPScurrentgcdrawable.

I think xdps/NSDPSContextWindow.h should include AppKit/DPSoperators.h
somewhere.