Le mercredi 23 décembre 2009 à 23:17 +0000, Graham Percival a écrit : > Yes; that's why we changed the hash calculation from self.ly() to > self.full_ly()
You meant the opposite. > -- produced lily-abcd1234 filename would not > depend on the fragment options, This is wrong. lilypond-book relies on hashing to decide whether a snippet should be (re)processed by lilypond, so framgent options that change processing by lilypond must be taken into account in the hash; that's why I started this thread to announce we should revert the commit 4c5a581ca25398669b9ecbc7a606febb09e60214 in some way. If we don't, then we can happily ignore all lilypond-book fragment options that have an impact on lilypond processing, as we won't ever be sure that they will be really respected by lilypond-book/lilypond :-) > I mean not using xx/lily-xxxxxxx.ly files for the regtests. > Instead, use files of the form: > out/lybook-db/regtest/xxxxxxxxxxxx.ly > where the filename is used directly. Like: > out/lybook-db/regtest/ancient-accidental.ly > out/lybook-db/regtest/slur-broken.ly > out/lybook-db/regtest/tuplet-numbers-avoid-slurs.ly This is doable and interesting to do for writing files in input/regression/out-www, but this makes no sense in out/lybook-db, where files should have a name predictable by lilypond-book (namely obtained using a hash), so it can decide for each snippet whether it's already been compiled or not. > ? All that will happen is that if somebody modifies a regtest > (like adding an additional bar to slur-broken.ly), that regtest > will show up in the regtest comparison for the next version. On > average I think that adds 3-4 images per release? You misunderstood me. I was afraid that the regtest comparison script would issue false positive differences because of a change in lilypond-book hashing, but maybe this fear is purely virtual. > The regtest naming issue should be fairly simple: add a new option > to lilypond-book that turns off the snippet hash calculation. > Wherever hash(self.ly()) is called, check the option and return > the filename if it's set. No, as I argumented at the beginning of this message, this would completely break the idea of a shared snippet database. However, a lilypond-book command-line option to write nice filenames in input/regression/out-www is fine, and will achieve what you explained above (regtest comparison is based on input/regression/out-www or its mirror in out-www/offline-root, right?). > Modify the stepmake/stepmake/ or > input/regression/GNUmakefile to add this option. Etc. OK for this point. > If you're not intersted, please add this to the issue tracker, and > I'll tackle it once I'm done the website. The problem is not that I'm not interested, but rather that I don't know the scripts that generate regtest comparison (so I don't know exactly what was the problem with 'make check'), while I'd like to make sure the efficiency of a shared snippet database for lilypond-book works well and is preserved. Best, John
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
