script/output-distance.py is broken. I suspect that the general out/lybook-db/ thing is the problem -- when I look at self.missing and self.added (say, adding a print to line 818 of scripts/build/output-distance.py ), I see tons and tons of files.
This is confirmed by the following test: gperc...@gperciva-desktop:~/tmp$ ls 2.13.3 lilypond-2.13.3-0.test-output.tar.bz2 2.13.5 lilypond-2.13.5-HEAD.test-output.tar.bz2 gperc...@gperciva-desktop:~/tmp$ find . -name "*.ly" | xargs grep accidental-ancient ./2.13.3/regression/out-test/11/lily-6a1f0270.ly:\sourcefilename "/home/lilypond/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/accidental-ancient.ly" ./2.13.5/regression/out-test/b4/lily-397060d1.ly:\sourcefilename "/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/accidental-ancient.ly" gperc...@gperciva-desktop:~/tmp$ I can't see how output-distance.py could track files across such changes. So... how are the directories and hashes generated? If it's machine-specific, then we have a hope -- we can't generate a comparison between 2.13.3 and 2.13.5, but at least later comparisons will be possible. If the hashes are based on the contents of the file, which I fear, then we're hosed whenever we update the version number of the regtests. :( Cheers, (?) - Graham PS I suppose we could change the hashing function to disregard any \version commands... but that still strikes me as fragile. Maybe the best solution is to not use the lybook-db for input/regressions ? _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
