Xprint cancer has infected libXaw

[Mike A. Harris]

In previous releases, Xprint could be disabled easily without any 
problems, however in current CVS, libXaw has a hard dependancy on libXp.
This causes the build to fail when "BuildXprintLib NO" is set, since Xaw 
unconditionally links to libXp.

As such, if you want to disable libXp, you have to disable libXaw, and a 
bunch of the Xaw using apps that come with the monolithic build, which 
isn't really acceptable, especially considering many 3rd party things 
use libXaw.

Before hard coded dependancies like this make it into the tree, I think 
there should be some level of public discussion about them.  If there 
was and I missed it, my apologies.  I didn't notice this problem until 
just a few hours ago when I initiated a build with
"BuildXprint NO, BuildXprintLib NO" set, so I'd not have know about this 
earlier, or I would have brought it up far earlier in the devel cycle.

BuildXprint itself is broken also, however I filed a bug and attached a 
patch to fix that.

The Xprint apps aren't wrapped in any define that I can see, however 
I'll whip up a BuildXprintClients Imake flag patch and submit it in 
bugzilla soon.

For the Xaw issue, there are a few solutions:

1) We could remove Xprint support from Xaw outright

2) We could conditionalize Xprint support in Xaw with BuildXprintLib
    wrapped around it, or some new BuildXawXprintSupport macro triggered
    from BuildXprintLib.

3) We could statically link Xaw to libXp.a if BuildXprintLib is set to
    NO, and then not ship the libXp headers, .a, or .so's

4) We could add stubs for the Xprint support in Xaw that return failure
    when called.

5) It could be changed to a new libXawXprint library which doesn't get
    built if Xprint isn't being built, so it isn't part of Xaw itself.


Personally I favour leaving Xaw as it was in 6.7.0, with no new 
features.  It is an ancient library that should just slowly die over 
time.  Adding new features (that nobody seems to want), and forcing 
people to ship it doesn't seem to be very popular in my discussions with 
a few people today.

Second to that, I'd go for the #5 solution of moving it to a new 
library, so the functionality is there for the few people out there who 
want Xprint support in Xaw apps.   It doesn't force people building Xaw 
to have to build and ship libXp also then.