Am Freitag, 29. Juli 2011, 12:55:09 schrieb Phil Holmes: > ----- Original Message ----- > > Currently, the doc build is calling lilypond in verbose mode, creating > > thousands of unnecessary lines like > > Reinhold - I've been looking at the build system in some depth and am very > well aware of this. I suggested turning off verbose mode and was told that > it was sometimes useful to see whay a build had failed.
Yes, I was told the same a long while ago, when I was also complaining about the verbosity. See e.g. the discussion: http://www.mail-archive.com/lilypond-devel@gnu.org/msg17212.html http://www.mail-archive.com/lilypond-devel@gnu.org/msg17243.html However, I have failed and still fail to see where the lilypond internals printed with --verbose can be helpful in any way during the docs build. Those verbose debug messages are useful for debugging a lilypond bug. However, in the docs build, we are not interested in how lilypond works internally, but rather where a doc build fails due to bad input in a .ly or .tely file. Printing the lilypond internals in the docs build does not help you find the typo in the docs. To the contrary, it might hide useful warning and error messages with excessive debug output. Problems in lilypond itself will/should be caught with make or 'make check', not with 'make doc'. Anyway, I think that the real problem is a layer deeper and that lilypond itself should get better error/warning/debug options. In particular, I'd like to propose several loglevels (in increasing verbosity, each one including messages from the ones above, too): -) NONE: No output at all, just a negative return code from the binary -) ERROR: output from error/programming_error (ly:error) -) WARN: output from current warning (ly:warning) -) PROGRESS: output from current progress_indication/success (ly:progress) -) INFO: output from current message (ly:message) function, i.e. what lilypond prints out currently -) DEBUG: Everything currently wrapped in "if be_verbose_global {...}", i.e. what --verbose does currently -) FULLDEBUG The loglevel would then be set as 'lilypond --log=WARN file.ly', with PROGRESS (or INFO) being the default, i.e. no change to the current output. Since we print all messages to stderr, there is no way to filter the output, so we need to add a command line option to lilypond to prevent printing undesired output in the first place (e.g. I have makefiles that call lilypond on several different huge files; there I'm not interested in the progress messages, just in the warnings and error messages. The --log=... option would allow exactly this). I think it would be really easy to implement those loglevels in LilyPond (actually, I have already started on it), because warn.cc already has basically the right structure. It just ignores whether a message is generated by the error, warning or progress_indication functions. The next step could then be a prettification of the lilypond-book output: We can add similar loglevels there, and even set a different loglevel for lilypond invocations (e.g. --lilypond-loglevel=...). When running lilypond- book, I'm not really interested in the progress messages for each included snippet. I just want to know which snippet is current processed. What do you think? Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
