libprinter.a .99 error ...?

[Keith Packard]

On Tue, 2005-07-12 at 00:49 +0200, Felix Schulte wrote:
> O
> 
> IMO this issue puts a big question mark behind the modularisation
> project. Parts of the xc tree uses shared source code 

Actually, only two parts do this -- xtrans and Xprt. For the former, we
had a solution in hand before the modularization work started --
providing xtrans as a 'source only' package and linking it into each
user. At some point, we should consider eliminating xtrans entirely as
it's quite ugly inside and only serves to complicate networking within
X.

No-one that I know of who is working on the modularization effort had
any idea that Xprt incorporated Xlib code in source form.

> source code duplication or addition of new dependencies are proper
> solutions for the modular tree.

We should consider any reasonable solution which avoids the current
monolithic issues of hidden dependencies. Right now, we've uncovered one
such -- Xprt depended on Xlib source code, a fact that was unknown to
most people and has come to light because of a strong effort to clean up
these kinds of short-sighted conveniences.

> Just declaring the issue a "bad design" choice (and I do not consider
> this as bad choice)

Using Xrm in Xprt is not a bad design choice, the only question is how
that code is incorporated into the Xprt binary. The effort to modularize
the X.org code base is driven, in large part, by a desire to make strong
interface guarantees so that individual parts of the system can be
updated without accidentally affecting the operation of disparate
pieces. By re-compiling Xlib code inside Xprt, you're breaking this
guarantee and placing additional demands on the Xlib maintainers.

It used to be that X was small enough for one person to grasp all of the
code. That's no-longer true, and we have an urgent need to encapsulate
as much complexity as we can so that mere mortals can continue to
distribute a working window system while controlling the effect of some
large scale changes which are needed to make X able to run reasonably
modern software.

>  does not make the problem go away and is no
> solution either. Neither is taunting of people who consider this a
> serious problem (IMO this should have been discussed and solved before
> the modularisation hacking started and not during the tree conversion
> process).

We thought we had solved the 'code sharing' issue when xtrans was
resolved. This Xprt code sharing wasn't a known issue.

I certainly expected to uncover problems of this nature in the process
of modularization; X has been around for long enough that all kinds of
evil hacks undoubtably lurk inside. Most of them are localized to a
single code base, which are generally solvable within the resulting
module. Only a few, fortunately, have exposed cross-module issues.

Also, you'll note that no tree-conversion process has started, the 7.0
work is all done in separate directories which link appropriate sources
in from the monolithic build, this permits cross-build environment
testing to ensure that any code changes made to help the modular build
system don't break the monolithic build.

Any change we decide to make for Xprt will be done for both monolithic
and modular builds to keep the two resulting releases as similar as
possible.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-modular/attachments/20050711/78c811a3/attachment.pgp