If "BuildXprintLib NO" is set, then libXaw will fail to build because it now has an unconditional hard dependancy to link to libXp. Previously libXaw did not link to libXp at all, which should still be possible for people who do not ship Xprint or it's clients or libraries.
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
(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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.