> 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.
Yep. > 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. I suggest a different route: Normally, after an error message has been emitted, a developer wants to debug the problem. In most cases, the problem is with the lilypond binary itself, so it would be most convenient if there is an easy way to find out how to call lilypond exactly. Currently, lilypond-book hides this very effectively, or the calling command is mentioned 100000 lines above in the log file... What about reducing the verbosity as much as possible, but make lilypond-book emit something like: Error `foo' encountered while processing file `file-XXX'! lilypond's error message: blablabla The used command line was FOO=bar lilypond --pdf -d... -d... file-XXX.ly A command line to debug the problem can be found in file `file-XXX-debug.sh'. if an error is happening? Werner _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel