lilypond-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]