On Tue, Sep 26, 2006 at 10:53:25AM -0500, Rex Dieter wrote:
| Here's a crazy-but-not-too-far-from-reality example: Build shared-lib
| pkg 'b' which links against 'a'. b's .la files now include
| to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which
| links against 'b', whose own libc.la file includes
| references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end
| up with a pkg z, and a libz.la, which, when all is said and done,
| * will have a direct dependancy upon y's liby.la
| * and because of liby.la file references/dependances, will have
| (indirect) dependancies upon liba.la, libb.la, ..., libx.la
| When, generally, *none* of these are really required nor desired.
I'm not sure about that, but maybe I understand something wrongly:
- If -la was needed for building libb, then there exists a real
dependency between liba and libb and libb.la is correct about that.
- If -la was unneccessary in building libb, libb.la will indeed
contain an unneccessary reference to liba. But that should be
considered a bug in the build of libb, or not? Fixing that bug may
also ease on the BuildRequires, so we should really be interested in
fixing such bugs.
In this simplistic view, *.la's are either in order, or there's a bug
that we'd like to remove anyway.
From a different view: *.la files aren't much different than *.pc
files, in fact they contain a subset of their information. One
wouldn't argue to remove all *.pc files because some may contain too
many references to libs.
Axel.Thimm at ATrpms.net