Xprint cancer has infected libXaw

[Jim Gettys]

On Thu, 2004-08-12 at 14:12, Mike A. Harris wrote:
> 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 certainly don't remember seeing any such discussion.

>
> 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.

Forcing Xprint it to be shipped seems badly wrong to me.

If Xaw picks up Xprint support, it should be optional, IMHO.
Even though I personally don't think Xprint is the right direction
in the long run, I don't greatly object to Xaw picking up support so
long as it is an optional feature.

A couple years ago I went through an exercise on the iPAQ, when
I discovered a set of dependencies that started from casual use of Xmu,
which pulled in Xt, which pulled in...

You get the drift.  And the Xmuu library was born (to solve these
interdependencies, that were soaking up a megabyte or more of my flash
on embedded systems.

4) is also acceptable to me.

> 
> 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.

                          - Jim