Unit tests of internal functions

[Greg Hudson]

On Mon, 2009-12-28 at 15:11 -0500, ghudson at MIT.EDU wrote:
> 1. Just export those symbols [...]
> 2. Make those symbols available through the accessor [...]
> 3. [...] build a second version of each shared library [...]
> 4. [...] build static versions of each library [...]

More on this, based on the feedback and my own investigation:

(3) would require a fair amount of hacking to shlib.conf, as the options
to process the export list are pretty deeply embedded there.  I think
the extra complexity would be more than this problem warrants.

It is hard to make (4) work such that only "make check" pays the time
and space penalty of building the static versions of each library.
Based on that and other negative feedback, I don't think we want to go
in this direction.

I think (2) might be too much barrier to entry for unit tests.  Unit
tests should be easy to write.  Currently going through the accessor is
a three-step process: adding the declaration to k5-int.h and bumping the
version, adding the initialization to os/accessor.c, and then using the
accessor in the calling code.  We could reduce the number of steps to,
but only by adding more build system complexity.

Currently I favor (1).  Sam suggested trying to do things the current
way before falling back to (1) or (2); I don't particularly like that
idea because the build system becomes fragile in the face of unrelated
future work-- when someone changes the C file containing the function
being unit tested, that can change the set of objects the test program
needs to link against.

I know some developers have concerns about people using internal
functions if we make it possible to do so.  My experience just doesn't
back up those concerns.  In my observation, if you label your internal
functions (as we do with the krb5int_ prefix) and don't prototype them
in your installed header files, people pretty much won't use them.  In
the very rare cases where they come up with a good enough reason to do
so, they will take responsibility for it if it breaks.  Observe that
very few open source libraries even have a Unix export list.

Regarding suggestions to comprehensively change the build system:

* Migrating from shlib.conf to a sort of mini-libtool script could make
it much simpler to implement (2), but I worry about the slippery slope
towards reimplementing libtool.

* I don't think we have any strong philosophical objections to using
libtool, but I believe init/fini support may be a blocker.  I may
investigate this further.  Using libtool would slow down the build a bit
and that would be sort of sad, but libtool is a de facto standard for
open source Unix library builds at this point.

* (This is pretty far off topic, but since it came up:) I don't think we
would get much out of using automake.  I am more interested in systems
such as CMake or SCons which would help us unify our Unix and Windows
build systems, but I'm not sure if either of them would turn out to be a
great idea.  I also don't see us putting the resources into a build
system migration at this time; we would benefit more from migrating our
test suite or version control system.