libtool: Postmortem

1 
1 1.4 A postmortem analysis of other implementations
1 ==================================================
1 
1 In all fairness, each of the implementations that were examined do the
1 job that they were intended to do, for a number of different host
1 systems.  However, none of these solutions seem to function well as a
1 generalized, reusable component.
1 
1    Most were too complex to use (much less modify) without understanding
1 exactly what the implementation does, and they were generally not
1 documented.
1 
1    The main difficulty is that different vendors have different views of
1 what libraries are, and none of the packages that were examined seemed
1 to be confident enough to settle on a single paradigm that just _works_.
1 
1    Ideally, libtool would be a standard that would be implemented as
1 series of extensions and modifications to existing library systems to
1 make them work consistently.  However, it is not an easy task to
1 convince operating system developers to mend their evil ways, and people
1 want to build shared libraries right now, even on buggy, broken,
1 confused operating systems.
1 
1    For this reason, libtool was designed as an independent shell script.
1 It isolates the problems and inconsistencies in library building that
1 plague 'Makefile' writers by wrapping the compiler suite on different
1 platforms with a consistent, powerful interface.
1 
1    With luck, libtool will be useful to and used by the GNU community,
1 and that the lessons that were learned in writing it will be taken up by
1 designers of future library systems.
1