Re: lilypond-book is hosed

[John Mandereau]

Le jeudi 24 décembre 2009 à 19:30 +0000, Graham Percival a écrit :
> Ah, we're talking about two different kinds of hashes.  One hash
> decides if the snippet should be (re)processed -- I don't care
> about that one.  Do whatever seems sensible for that.
> 
> The other kind of hashing produces the lily-xxxxxxxx.ly filename
> based on the contents.  *That's* the kind that we (intentionally)
> changed to be independent of snippet options, in order to have the
> same filename produced for regtests with different options.
> 
> That change seems to have disturbed the first kind of hashing,
> though.
> 
> 
> ** edit: rather, there are two *goals* of hashing in
> lilypond-book.  Technically, they seem to be generated via the
> same mechanism, which is the cause of this whole problem.  But we
> avoid that problem by using the regtest filenames, so that's fine.

This makes no sense.  Between two lilypond-book invocations, hashes are
not stored in any other place than in the filenames, so if lilypond-book
has to decide whether to rebuild a snippet, it can only do this by
comparing the computed hash to the hash in a filename, so there is no
way that filenames hashes should be generated with another hashing
mechanism, unless you store the actual hashes in some database.


> Doesn't input/regression/out-www/ use out/lybook-db ?

Yes, lilypond-book hardlinks output files from the second directory to
the first one.


> The bottom line is this: I'd like a regtest processed with one set
> of options to have the same filename as that same regtest
> processed with another set of options.  I don't care what you do
> to either set of hashes, as long as that goal is met.  :)

This goal makes sense only for test-baseline and check targets, right?
(see my final comment below)


> Whatever happens, I'll need to generate a new set of 2.13.9
> regtests with the new filename-hashing (or
> regtest-filename-keeping) in order to compare them with the
> 2.13.10 regtests.

OK.


> Sorry, I was only intending to propose this for the regtests, not
> the normal docs.

For 'doc' target, normal docs and regtests share the same snippet
database, so I'd rather not change filenames of regtests output when
building this target.

Best,
John

signature.asc
Description: Ceci est une partie de message numériquement signée