libprinter.a .99 error ...?

[Egbert Eich]

Keith Packard writes:
 > On Wed, 2005-07-13 at 19:18 +0200, Egbert Eich wrote:
 > 
 > >    - We treat it like a header file (that's what we do for xtrans,
 > >      however here we have no choice as it is built in different ways
 > >      depending on the environment, how is controlled by numerous defines
 > >      ) 
 > 
 > Xtrans was uniformly treated like this in the old build system; all of
 > the symbols in that library get re-named depending on which system is
 > incorporating the code, so there wasn't any way to create a shared
 > library.
 > 
 > >    - Since it is linked into a shared library anyway we can obtain its
 > >      functionality by linking against this shared library.
 > 
 > This works fine and seems like the best method here as the code was
 > already designed to be included in a shared library.
 > 
 > Is anyone having trouble with Xprt at this point? It should all be
 > working now that it links against Xlib.
 > 

I haven't seen any complains so far and also noone has brought up evidence
yet that the memory footprint of Xprint has grown considerably compared
to the version with Xrm.c code compiled in directly.

 > >    - The object file could be 'installed' on the system for consumption
 > >      by other builds.
 > 
 > That's just a static library, which already exists as libX11.a. Of
 > course, using that would bring a bit of Xlib along as Xrm.c isn't
 > compiled to strip out calls into the rest of Xlib. We could construct a
 > separate library that compiles Xrm.c without Xlib hooks and install that
 > alongside Xlib for use by Xprt, but you only save memory when running
 > Xprt without using any other Xlib applications. I don't think this makes
 > a lot of sense.

Right, it would only make some sense if Xrm.c would not reference any
other pieces of Xlib. Certainly it could be split to do so, however
unless there is a compelling reason one should probably not go this
route.

 > 
 > Right, I think we need to treat each sharing of source code on a
 > case-by-case basis and figure out the right solution. In this case, I
 > don't see a good reason to share at the source level because the two
 > usages can share the same binary version.

Actually this was an easy one to deal with - except ...

 > 
 > For xtrans and mesa, we can't share at the binary level because they are
 > compiled very differently in each environment they're used in, so
 > source-level sharing is necessary.
 > 
 > I think we've demonstrated that the new build system is capable of
 > supporting several different solutions and that we should feel free to
 > select the 'best' one in each case.
 > 

Right :-)

Cheers,
	Egbert.