[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GOP-PROP 5: build system output (probable 2?)
From: |
Reinhold Kainhofer |
Subject: |
Re: GOP-PROP 5: build system output (probable 2?) |
Date: |
Fri, 29 Jul 2011 17:46:45 +0200 |
User-agent: |
KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.5; i686; ; ) |
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/address@hidden/msg17212.html
http://www.mail-archive.com/address@hidden/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, address@hidden, 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
- Re: GOP-PROP 5: build system output (probable 2?), Jan Nieuwenhuizen, 2011/07/28
- Re: GOP-PROP 5: build system output (probable 2?), Werner LEMBERG, 2011/07/29
- Re: GOP-PROP 5: build system output (probable 2?), Reinhold Kainhofer, 2011/07/29
- Re: GOP-PROP 5: build system output (probable 2?), Phil Holmes, 2011/07/29
- Re: GOP-PROP 5: build system output (probable 2?), Graham Percival, 2011/07/29
- Re: GOP-PROP 5: build system output (probable 2?), Graham Percival, 2011/07/29
- Re: GOP-PROP 5: build system output (probable 2?), Neil Puttock, 2011/07/29
- debug spam (was: GOP-PROP 5: build system output (probable 2?)), Graham Percival, 2011/07/30
Fwd: Re: GOP-PROP 5: build system output (probable 2?), Reinhold Kainhofer, 2011/07/29