Bug 1060

Not to mention that Xaw itself should not be encouraged to live by adding
new features that aren't wanted...

On today's release wranglers call we decided that the interface changes to
libXaw should not have been made, but we failed to recognize them until now. 
For this release, we will back out the changes and suggest that a separate
library be created to handle the Xprint code.  Since we failed to recognize this
problem until now, that new library, along with any hooks in Xaw (if they are
not too intrusive) to make it work properly, will be allowed into the release.

Created attachment 633 [details] [review]
xaw xprint revert patch

The changes to Xaw are not too intrusive and can be reverted quite easily. 
However a few of the applications have been changed to use the new
XawPrintShell widget unconditionally.  I've chosen to revert those applications
to their revisions before the Xprint functionality was added.

I we decide that these applications should use Xprint conditionally, we can add
that after the release, but with the code freeze coming up Monday I don't think
we can do anything but roll back the changes.

Finally, xmore is a new application that was recently added to the distribution
(see bug #611) and has always required XawPrintShell.  I dont see any solution
to this other than to disable xmore in the build at this point.  After the
release we can reconsider (or rather, consider) xmore's inclusion in the tree.

Details:
    xman has been reverted to June 5
    xlogo has been reverted to May 8
    xedit has been reverted to April 25

Created attachment 638 [details] [review]
xaw xprint revert patch

Updated patch.	In addition to the changes described in comment #3, this patch
makes the following changes:

    config/cf/X11.tmpl: Fix up config logic to be like the rest of the
extensions: BuildXprint is a one-stop option for disabling everything Xprint
related.  XprtServer controls building Xprt, BuildXprintLib controls building
Xprint libs and BuildXprintClients controls building clients related to Xprint.
 BuiltXprint defaults to YES and the other options respects relevant settings,
i.e. BuildServer and BuildServersOnly.

    lib/Imakefile: build Xaw regardless of BuildXprintLib setting

    programs/Imakefile: only build xphelloworld, xplsprinters and
xprehashprinterlist when BuildXprintClients it YES

    xdpyinfo,xset,glxgears: make Xprint support conditional, depending on
BuildXprintLib

I'm doing a make World test for the patch, once with BuildXprint NO and once
with BuildXprint OFF to be sure everything works.  I did test it incrementally,
but these two runs should make sure it builds from scratch.

(In reply to comment #4)
> ...
> I'm doing a make World test for the patch, once with BuildXprint NO and once
> with BuildXprint OFF to be sure everything works.  I did test it incrementally,
> but these two runs should make sure it builds from scratch.

OK, these builds are done now and they both came out well: the BuildXprint NO
run installs no Xprint related files, the BuildXprint YES installs all the
expected files.

Patch committed after being discussed and accepter at the release wranglers
meeting on August 16.

Closing bug.

Seem to have missed a place when BuildXprint is YES (i.e. the default with no
settings):

making all in programs/xphelloworld/xpawhelloworld...
cc -xO4 -xbuiltin=%all -xlibmil -xstrconst -xarch=v8plus -Xa -v -zlazyload
-zcombreloc -xstrconst -xildoff   -I/usr/X11R6/include  -I../../..
-I../../../exports/include   -Dsun -Dsparc -DSVR4 -D__EXTENSIONS__        -c 
xpawhelloworld.c
"xpawhelloworld.c", line 44: cannot find include file: <X11/Xaw/Print.h>

Probably need to disable the build of xpawhelloworld until the Xaw/Xprint
replacement library is ready.

Created attachment 656 [details] [review]
Disable building xpawhelloworld

The attached patch should fix this problem.  If it does, I will apply it.

I went ahead and applied this change since it should be safe.

Created attachment 657 [details] [review]
change order of xprint libs in glxgears

on cygwin the link order is important.
change $(XPLIB) -lXprintUtil to -lXprintUtil $(XPLIB)

still issues on cygwin (last patch). Reopening

still issues on cygwin (last patch). Reopening

(In reply to comment #7)
...
> Probably need to disable the build of xpawhelloworld until the Xaw/Xprint
> replacement library is ready.

That is odd, I didn't get this error when I did the default make World.  Doesn't
make World remove xc/exports?  I didn't use a clean tree though, I just did make
World in a tree I had been using for a while, and if the
xc/exports/include/X11/Xaw links doesn't get removed...

Kevin, I agree with the patch, I just missed that one.

(In reply to comment #12)
> still issues on cygwin (last patch). Reopening

Oh sorry, this bit was applied after the Xprint changes, but I missed it in the
patch.  Should be good to apply, since it was already in the tree.

http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/programs/glxgears/Imakefile?r1=1.3&r2=1.4

Checked in the change for cygwin.
Closing.

The changes made here are COMPLETELY INACCEPTABLE. Reopening for further
discussion.

Note:
1. Even Motif, Mozilla, Eclipse etc. _ALL_ depend on libXp.so. You cannot ship
X11 without libXp withoput breaking lotsof applications and making libXaw depend
on libXp is the logical consequence of adding print support to it. And NO, this
support cannot be put into a seperate library for the obvious reason that the
widget classes need internal libXaw data.
2. I am VERY VERY angry about this backout of nearly one year of work made by
various people.

Roland,
Does setting 'BuildXprintLib NO' still cause the libXaw build to fail? If so,
please fix it; if not, please retitle the bug report when reopening bugs like this.

Also, please stay calm.