----- Original Message -----
From: "Julien Rioux" <[email protected]>
To: "Phil Holmes" <[email protected]>
>
> 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.
Regards,
Julien
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
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
