libprinter.a .99 error ...?

[Egbert Eich]

Dave Airlie writes:
 > 
 > I think you are going a bit over the top, it is a bad design choice
 > and probably should never have been let into the tree at all ..  but
 > its in there now and it isn't going to stop modularisation....

Nor should it but it's one thing that needs to be dealt with.
Instead of calling things 'bad design' that don't fall into place
right away we should use this as an opportunity to proove that the
new build system is flexible enough to handle this situation.

It's conceivable that in a large project there is code that is
useful in more than one place. Surprisingly there are such a few
places where anything like this happens.

It makes sense to avoid duplication, so what are the options?
Here is what comes to my mind:

   - 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
     ) 
   - Since it is linked into a shared library anyway we can obtain its
     functionality by linking against this shared library.
   - The object file could be 'installed' on the system for consumption
     by other builds.
   - 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.

 > 
 > can we just link ,v files in CVS behind the scenes? hard or soft
 > should work... granted if one gets updated you get sneaky updates into
 > the other tree.. actually that is a sick idea...
 > 
 > someone want to make another shared lib ? :-)
 > 

Egbert.