Hello, On 30 September 2012 16:06, Thomas Morley <thomasmorle...@googlemail.com> wrote: ...
>>> Please see >>> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log >>> >>> make[2]: *** [out-test/collated-files.texi] Error 1 >>> make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression' >>> make[1]: *** [local-test] Error 2 >>> make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression' >>> make: *** [test] Error 2 >>> %%%%%%%%%%%%%%%% >>> >>> Looking at: >>> >>> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log >>> >>> The file contains nothing else than: >>> GNU LilyPond 2.17.4 >>> >>> >>> Obviously I did sth wrong and again I've no clue what and how to proceed. >> >> Why do you think you did something wrong? > > Well, I'm still a newbie with this kind of tasks. > If sth crashes my first thought is, damn, what did _I_ wrong. > >> That was exactly what I got when I tested the patch originally. >> >> You need to find the problem of why it failed to compile. >> >> See >> >> http://code.google.com/p/lilypond/issues/detail?id=2790#c33 >> >> Did you get the same problem? > > I couldn't comprehend your own work. The problem is that not all errors are the same - I am no expert but after testing patches for the last year or so, you get a feel for this I guess. Phil's work (et al) has helped simplify the log, but if you see http://code.google.com/p/lilypond/issues/detail?id=2790#c16 for instance, this was a differnet kind of failure and was easy to spot simply because the log file references did point to a .ly file. This instance here is different and so it was trickier to follow the chain, in fact I couldn't. Phil's suggestion of looking at the latest file generated is a good one, but I simply use basic grep commands grep -r -C 10 "Error" for instance, in the top level of the build dir. I get a ton of hits, but the -C makes it easy to see if the return is just a comment of the string 'Error' or a function call, rather than a log file. The trick here is to know the error message being generated in the log file, "fatal" is one, or you can just do "Processing files" and the -C gives you a few lines above and below so you can see a completed file or an error. > But after typing 'make check' the first two lines the terminal returns are: > > For tracking crashes: use > > grep sourcefilename `grep -L systems.texi > out/lybook-testdb/*/*log|sed s/log/ly/g` I can't comment on that but it seems awfully complicated. > > Trying to enter this (in the build-directory) returns: > \sourcefilename > "/home/harm/lilypond-git/input/regression/instrument-name-volta.ly" > > This is exactly the file Marc mentioned here: > http://codereview.appspot.com/6498052/#msg13 OK but that ly file will also occur in a snippet*.log file. So you can cross reference I guess but that would need another grep search. I guess I am just used to looking at lines and lines of output to use a simpler grep command, but not all crashes/compilation failures are the same and don't generate the same error messages even if the initial crash message looks the same. At least from my experience. However the offending log file *will* contain the error message (as if you had run lilypond-book on the individual snippet) Hence my comment --snip-- lily-7dccbf09.log:programming error: number of pages is out of bounds lily-7dccbf09.log:programming error: tried to space systems on a bad number of pages lily-7dccbf09.log:programming error: number of pages is out of bounds lily-7dccbf09.log:programming error: tried to space systems on a bad number of pages --snip-- The file 'lily-7dccbf09.log' contained the error message (from the grep command) and also in that log was the name of the snippet. James James _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
