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: Phil Holmes
Subject: Re: GOP-PROP 5: build system output (probable 2?)
Date: Fri, 29 Jul 2011 17:05:40 +0100

----- Original Message ----- From: "Reinhold Kainhofer" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: <address@hidden>
Sent: Friday, July 29, 2011 4:46 PM
Subject: Re: GOP-PROP 5: build system output (probable 2?)


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.

Well, I clearly agree. However, just pushing the output to log files effectively does the same thing.

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.

Think this risks over-gilding the lily, TBH. Personally, I've never used verbose. We already have an option to suppress output/direct to logfile -dgui.

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 remain of the view that this is wrong, and at some point there's likely to be a GOP discussion. FWIW make sends progress to stdout and error to stderr...

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?

GOP

--
Phil Holmes





reply via email to

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