Am Freitag, 29. Juli 2011, 18:56:36 schrieben Sie:
> 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,
That's where I would disagree. Typically a *doc* build fails due to a typo
in
the documentation (i.e. wrong lilypond code in an example included in the
docs).
All problems with the lilypond binary itself should have already failed
the
regtests (in theory, of course).
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?
Yes, that would be *extremely* helpful (not only for the lilypond
documentation, but also to other lilypond-book users). The only question
is:
who will implement it? ;-)