[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Various updates to reduce make doc output (issue 5727055)

From: Phil Holmes
Subject: Re: Various updates to reduce make doc output (issue 5727055)
Date: Wed, 14 Mar 2012 08:56:26 -0000

----- Original Message ----- From: "Julien Rioux" <address@hidden>
To: "Phil Holmes" <address@hidden>
> It seems just not worth it. We _never_ want to check warnings as part of
> make doc. That's what regression tests are for.
> --
> Phil Holmes

I disagree, make -s doc is useful to identify warning messages that
need fixing, and the log files are also useful for this. I think that
the progress messages are what you should focus on silencing. The
warning messages should be either fixed at the source or left in place
so that someone eventually decides to fix them at the source. In this
particular case, it might be that nobody will ever work to improve
midi2ly, but that's not for us to say.


Sorry - I expressed myself badly. I meant that we shouldn't use make doc to check that warnings that we expect to appear do, in fact, continue to appear. We should use make test to check that the "correct" warnings continue to be output. I agree 100% that make doc _should_ make it easy to find new warnings we were unaware of.

The problem with this one is that Lilypond (like Sibelius...) only provides 4 voices to allow notes to avoid colliding on a stave. I haven't delved deeply into midi2ly, but my assumption is that it maps midi channels on a single stave to different voices. The "offending" midi file has more that 4 channels on a stave and therefore the mapping to 4 voices is never going to work properly - and so midi2ly warns the user. But we don't want to continue to see those warnings on the screen, hence the suppression with -q. I can't see why an interactive user would use -q, so it won't give them a problem. I also don't believe that having another logfile solely to contain the message "warning: found more than 5 voices on a staff, expect bad output" makes much sense. Hence the way I went.

Phil Holmes

reply via email to

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