Unit tests of internal functions

[Jeffrey Hutzelman]

--On Monday, December 28, 2009 04:51:53 PM -0800 Russ Allbery 
<rra at stanford.edu> wrote:

> FWIW, I'm moving all of my packages to Automake and Libtool, and while
> that approach is not without problems, I think it's the right direction to
> go.  It means that there's at least some hope that other people have
> already run into whatever weird build problem you have and have written
> recipes to deal with, or even taught Automake and Libtool about it
> directly.  Upstream on both projects is fairly responsive.
>
> Also, there's the general advantage that a lot more people out there know
> Automake and Libtool than know the build system of any single project,
> which means it's more likely that you can find people who can patch your
> build system.

Libtool sucks.

However, as someone who builds and deploys a lot of software, my preference 
is that _every_ package that builds shared libraries uses libtool.

Why?  Because it turns out that some of the most annoying problems can be 
made to go away with a relatively minor patch to libtool, at the expense of 
making it not work at all on a couple of platforms I happen not to care 
about.  We locally maintain patched libtool, and simply relibtoolize each 
package as it comes in.  We also maintain local patches that help us adjust 
the soname of every shared library to depend on the versions of its 
dependencies.  So, for example, a (Heimdal) libkrb5.so built against 
OpenSSL 0.9.8 will have a different soname from the same version of 
libkrb5.so built against OpenSSL 0.9.7.  This turns out to be really 
important when you have complex applications with multiple direct and 
indirect dependencies on the same library.

Anyway, the point is, if a package uses libtool, I can get all the special 
behavior I need by relibtoolizing.  If it doesn't, I get to figure out how 
its super-special shared-library build system works.

So, libtool sucks, but please, use it anyway.

-- Jeff