[Testtools] An anomalous failure in nightlyBuild

[Lou Hafer]

Gents,

	I've been gradually trying to sort out a failure in nightlyBuild.  It's
taken a bit of time because I'm not yet entirely familiar with the architecture
of the nightlyBuild code, because there were multiple problems, and because I
muddied the water quite a bit, but I think I can explain it now.

	Around Dec. 29th, Stefan updated get.Glpk to Glpk 4.34.  Apparently
Andrew did a major reshuffle of subroutines within files, or perhaps renamed
files.  Make recompiled only a few glpk files.  The failure occurred in
CoinUtils.  The final link for libCoinUtils spat out a huge number of error
messages about multiple definitions for glpk subroutines, and died.  I noted
this and resolved I'd look at it after New Year's.

	As it turned out, it was Jan. 3rd by the time I got around to doing
some work, and by then Stefan had found a symbol problem in glpk and updated the
glpk.patch file.  Unfortunately, Solaris patch is a backward old version and it
choked on the patch file format.  So the patch error caught my eye first, and I
fixed it.  Then I blundered while trying to force nightlyBuild to recognise the
change.  I needed a few manual runs of get.Glpk to get it right.  nightlyBuild
doesn't consider changes to the .patch file, and concluded it had the latest
version and there was no need to configure.  But downloading glpk erases
config.h --- a dummy file that's created by configure to satisfy the needs of
HAVE_CONFIG_H.  Being a bright sort, I reasoned that removing the
ThirdParty/Glpk subdirectory from the source and build directories ought to do
the trick, and I plowed ahead. In retrospect, removing NBinstalldone would have 
been a bit more precise, but might not completely solve the problem.

	I run nightlyBuild four times, covering two of eight builds with each
run and changing build environment between runs.  The first run neatly restored
ThirdParty/Glpk from the repository, ran get.Glpk, configure, make, make test,
and all was copacetic.

	The remaining runs concluded that the source was unchanged, skipped
configuration, and proceeded to fail on make because there was no
ThirdParty/Glpk subdirectory in the build directory.  In the end, I restored
them by doing the configure runs by hand. nightlyBuild now seems happy again.

	I'm not sure there's any easy way to correct any of these issues, but
you who are more familiar with the design of TestTools might see something.

	For the Dec.  29th failure, a `make clean' in ThirdParty/Glpk would
probably have been sufficient. But as a general policy (`make clean' after
configuration) this might be a dramatic increase in workload.  Arguably, changes
to a .patch file should result in code changes that are picked up by make, with
no further action by nightlyBuild.

	For the Jan. 3rd failure, it seems to me that a check for the presence 
of the relevant build directory is needed. But what if the user deletes some 
random subdirectory in the build directory? I don't know that there's a 
foolproof solution. Arguably, this is user error.
	
	A long ramble, but I thought this should be written down somewhere.
	
								Lou