Re: [Lilypond-auto] Issue 4342 in lilypond: Patch: Replace C++ (in)equality checks with proper SCM syntax

[lilypond]

Comment #12 on issue 4342 by address@hidden: Patch: Replace C++  
(in)equality checks with proper SCM syntax
https://code.google.com/p/lilypond/issues/detail?id=4342

Valentin,

yes you must do the 'configure --disable-optimising' (as that is what  
Patchy uses to test as well).

As I run the patchy script the location of the output files are going to be  
different than where yours are and there are additional log files generated  
by the 'automated build' which help simplify following the trail down. I  
think these are just judicious output you would see on the screen sent to a  
log file - which you may lose I guess unless your terminal buffer is large.

However essentially after the patchy script reports a failure and gives me  
a patchy log file to look at, I can then see that from that patchy log  
which of the 'snippetnames' files in the ../out/lybook-testdb/.. reports  
the error.

Now, if I am lucky, I can see which specific snippet file has failed and it  
is obvious from the snippetnames log file where to go to to check; but  
running a multicore make check usually means that when the make check test  
fails, there are a LOT of other snippets also being processed and the  
logging doesn't normally give an indication which of the snippet files  
borked. Make doc failures are much simpler to analyse.

Then depending on how much time I have to go and hunt the problem and what  
the error message shows from the log file, but if it is looking like it is  
going to be hard to find the specific files reporting the problems, I then  
usually just end up grepping for '[Ee]rror' and '[Ww]arning' in  
the ../out/lybook-testdb/.. directory.

I know this is crude as there are a lot of files that contain commented  
code with the words 'Error' or 'Warning' in them, but after a while you do  
get practiced at sorting out the 'wheat from the chaff' (as we say here)  
and I try to do even this very crude check just to try to give the  
developer some chance to know what is going on. Else all they get is 'make  
check' failed from me and nothing more, which isn't helpful as building the  
tests can take time on less powerful computers.

Anyway, let me re-run the automated tests on your Patch set #4 and see what  
I can find.

James

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings