Minutes from X.Org Architecture Call for 30 August 2004

[Adam Jackson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 31 August 2004 10:00, Roland Mainz wrote:
> Keith Packard wrote:
> > The current Xprint support in Xaw can be trivially split out into a
> > separate library (we have a proof-of-concept today).  However, Roland
> > asserts that such a split will hamper his future Xprint/Xaw plans.
>
> One simple question:
> The option of putting XawPrintShell into a seperate library has already
> been _REJECTED_.
> And I thought I made it clear that I am not carrying the extra wheight
> of a misdesign which puts XawPrintShell into a seperate library just
> because some people rant loudly against that without coming up with
> valid reasons why Xprint support should NOT be part of libXaw. And a
> seperate shared library just for one widget class is a waste of time and
> resources - and a nightmare from the maintaince-"point of view". And it
> has already been said: One such a design has been chosen there will be
> NOT WAY to undo that without new pain (like breaking binary
> compatibility).

You keep bringing up binary compatibility as though it were a relevant issue.  
If I want an Xprint-free system, then clearly I'm okay with having apps that 
depend on XawPrintShell not work, since I already stated that preference at 
build time.  Xaw apps that don't require XawPrintShell will work just fine 
either way.  That's just how symbol resolution works, if you never ask for a 
symbol, you can't fail when it doesn't exist.

If this isn't what you mean by binary compatibility, then I apologize, and 
would like to know what you do mean by binary compatibility.

> In libXaw the widgets tightly depend on each other, too. Moreover: In
> all the history of the Athena widget sets the core Athena widgets were
> kept together in the libXaw library and noone ever thought to modularise
> the library into one-shared-library-per-widget-class.

In libXaw, no other widget depends on another client-side extension library.  
I can guarantee you that if someone introduced a hard build-time dependency 
on PEX in Xaw there would be similar kicking and screaming.

That is what #1060 is about, after all.  The Xprint support in Xaw introduced 
a hard build-time failure when attempting to configure X without Xprint 
support.  And I really don't care what the solution is, so long as I can 
build X without Xprint, the way I can build X without Render or GL or DMX 
or...

It's about orthogonality.  If we're going to have multiple projects in the 
same tree, they all have to be responsible for not stepping on each others 
toes.  When DRI causes a build failure for a non-DRI platform, that's DRI's 
problem to fix.  Xprint is no different in this regard.

There's a half-dozen closed bugs in Bugzilla about build failures when 
disabling parts of the Imake machinery - that you reported, Roland.  If you 
consider building without DPMS or XEVIE or FIXES to be valid configurations 
that the user might request, then it's only fair that you allow that others 
might want to build X without Xprint.

- - ajax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBNJZNW4otUKDs0NMRAsnsAKDlu+5+CUkroBri9zKVObmuqtsqQgCgyvEF
FlR7i/Bi00M6aSAWrgwvwEo=
=RX1t
-----END PGP SIGNATURE-----