Bug 1273 - Bump major version of libXaw
Summary: Bump major version of libXaw
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xaw (show other bugs)
Version: git
Hardware: x86 (IA32) All
: high normal
Assignee: Kevin E. Martin
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 351 1254
  Show dependency treegraph
 
Reported: 2004-09-01 18:06 UTC by Kevin E. Martin
Modified: 2004-10-03 14:14 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xaw patch (48.26 KB, patch)
2004-09-01 18:10 UTC, Kevin E. Martin
no flags Details | Splinter Review
Restore original xedit, xman, etc. functionality (patch for 2004-09-02-trunk) (130.57 KB, patch)
2004-09-01 22:30 UTC, Roland Mainz
no flags Details | Splinter Review

Description Kevin E. Martin 2004-09-01 18:06:08 UTC
As described in the links below, the architecture board voted to bump the major
version number of the libXaw library.

http://freedesktop.org/pipermail/release-wranglers/2004-August/000970.html
http://freedesktop.org/pipermail/release-wranglers/2004-September/000982.html
Comment 1 Kevin E. Martin 2004-09-01 18:10:30 UTC
Created attachment 810 [details] [review]
Xaw patch

This patch bumps the major version number of libXaw and creates a frozen
libXaw7 version as described on the architecture call (30 Aug 2004).
Comment 2 Kevin E. Martin 2004-09-01 18:15:26 UTC
Actually assigning to myself this time.
Comment 3 Roland Mainz 2004-09-01 18:25:01 UTC
Two questions:
1. The following change looks strage:
-- snip --
--- programs/xdpyinfo/Imakefile 16 Aug 2004 16:36:15 -0000      1.5
+++ programs/xdpyinfo/Imakefile 2 Sep 2004 01:05:17 -0000
@@ -62,7 +62,7 @@
            DMXLIBS = $(DMXLIB)
 #endif
 
-#if BuildXprintLib
+#if BuildXprintLib && BuildXprintClients
      XPRINTDEFINES = -DXPRINT
         XPRINTLIBS = $(XPLIB)
 #endif
-- snip --
Both "xdpyinfo" and "xset" are more or less "generic" control applications and I
am not sure whether the extra dependicy on |BuildXprintClients| is needed
here... or is it ?

2. The changes to "xedit" and "xman" seem to be lost - should I fix that ?
Comment 4 Kevin E. Martin 2004-09-01 19:00:00 UTC
(In reply to comment #3)
> Two questions:
> Both "xdpyinfo" and "xset" are more or less "generic" control applications and I
> am not sure whether the extra dependicy on |BuildXprintClients| is needed
> here... or is it ?

It is needed for vendors who choose build clients that do not depend on Xprint.
 This is very important.

> 2. The changes to "xedit" and "xman" seem to be lost - should I fix that ?

I haven't gotten to those yet.  I'm just going through all of the other bugs
first.  I already added the xlogo changes back in.  I was going to start on
adding the xedit and xman changes back in next.  If you would like to do that,
then that would be great.  Otherwise, I'll take care of it in a little while.
Comment 5 Roland Mainz 2004-09-01 19:05:06 UTC
Kevin E. Martin wrote:
> (In reply to comment #3)
> > Two questions:
> > Both "xdpyinfo" and "xset" are more or less "generic" control applications 
> > and I
> > am not sure whether the extra dependicy on |BuildXprintClients| is needed
> > here... or is it ?
>
> It is needed for vendors who choose build clients that do not depend on 
> Xprint.
> This is very important.

Ah, OK...

> > 2. The changes to "xedit" and "xman" seem to be lost - should I fix that ?
>
> I haven't gotten to those yet.  I'm just going through all of the other bugs
> first.  I already added the xlogo changes back in.  I was going to start on
> adding the xedit and xman changes back in next.  If you would like to do that,
> then that would be great. 

I can do that... it will need around ~~75mins from now...
Comment 6 Roland Mainz 2004-09-01 22:00:04 UTC
OK, I am done... I have one final nit:
The code test for the CPP symbol |XPRINT| (better would be something like
|BUILD_PRINTSUPPORT| (two words - just to avoid the xx@@!!-namespace cliff)) -
which shouldn't be done since that symbol is already "in use" by the Xprint
server side (and both sides shouldn't use the same CPP symbols - at least
applications like Xnest will suffer from that) - can I fix that, too (I already
avoided that for the xedit/xman code, but I see the same uglyness in the
glxgears, xdpyinfo, xset, etc. code  ;-(( ) ?
Comment 7 Kevin E. Martin 2004-09-01 22:04:22 UTC
That's fine.  Changing the defines from XPRINT to something else is easy to do.
 I'll do that when I check in your patch.
Comment 8 Kevin E. Martin 2004-09-01 22:27:02 UTC
Okay, I've changed all of the #ifdef XPRINT to #ifdef INCLUDE_XPRINT_SUPPORT
I'm also fixing some build problems with BuildServersOnly.
I'll check these in after I finish the testing.
Comment 9 Roland Mainz 2004-09-01 22:30:32 UTC
Created attachment 814 [details] [review]
Restore original xedit, xman, etc. functionality (patch for 2004-09-02-trunk)
Comment 10 Roland Mainz 2004-09-01 22:37:05 UTC
Comment on attachment 814 [details] [review]
Restore original xedit, xman, etc. functionality (patch for 2004-09-02-trunk)

Can I commit this patch, please ?
Comment 11 Kevin E. Martin 2004-09-01 22:44:51 UTC
I am working on finishing up my patch, and then I will commit yours.
Comment 12 Kevin E. Martin 2004-09-02 01:40:42 UTC
Okay, I've checked your patch in.  It looked fine.  I made a few minor changes
to make xman and xedit use #ifdef INCLUDE_XPRINT_SUPPORT (for consistency) and
to expose the print button (xedit) and the print menu option (xman) only when
building with Xprint support.
Comment 13 Roland Mainz 2004-10-01 18:57:59 UTC
Kevin:
Can we close this bug or is there anything ToDo ?
Comment 14 Kevin E. Martin 2004-10-04 07:14:06 UTC
Yes, this can be closed since the code has been checked in.
Closing.


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.