[Testtools] An anomalous failure in nightlyBuild

[Stefan Vigerske]

Hi,

wow, this must have been the first posting on this mailing list ;-).

The ThirdParty/Glpk update + nightly build issue is not perfect.
Normally I just correct the symptons by hand.

> 	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.

Could the problem be that the newly installed glpk sources maintain they
original modification date, so that make does not rebuild them all?
I now added a "touch glpk/src/*.c glpk/include/*.h" to get.Glpk to
(hopefully) force rebuild of all source files.

> 	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.

Thanks for the fix. Hmm, I though my patch file works on Solaris, the
new patch was extra for sun systems.

> 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.  

Creating config.h in configure did not seem to be the best idea, though.
I tried to move this into the Makefile now:

libcoinglpk_la_DEPENDENCIES = $(srcdir)/$(GLPKDIR)/include/config.h

$(srcdir)/$(GLPKDIR)/include/config.h :
	echo "" > $(srcdir)/$(GLPKDIR)/include/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.

We could put something into the TestTools scripts to conclude that if a
.patch file changes it should rerun the get.* script. Currently it
compares only the date of NBinstalldone with the get.* command.
It will need some coding around NBbuildConfig.py line 365.

> 	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.

Yes, this is user error. The build directories created by nightly build
are not meant to be "touched" by the user ;-). If a user starts changing
around there, then nightly build will not try to figure out what it has
to do to get things correct again.

> 	A long ramble, but I thought this should be written down somewhere.

Thanks, it's great to get this kind of input and wonderful analysis :-).

Thanks again,
Stefan