libprinter.a .99 error ...?

[Keith Packard]

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.

>    - 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.

>    - If more such cases (files) existed (which doesn't seem to be the case)
>      they could be compiled either in a separate base module or along with
>      some module that would qualify as such then archived together (as 
>      a normal ar archive not in a shared lib as they would have to be 
>      extracted form this archive when used) and installed much like 
>      Xtrans.c and friends.

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.

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.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050713/7a90a2fa/attachment.pgp>