lilypond-devel
[Top][All Lists]
Advanced

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

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


From: Julien Rioux
Subject: Re: Various updates to reduce make doc output (issue 5727055)
Date: Tue, 13 Mar 2012 15:14:27 -0400

On Mon, Mar 12, 2012 at 6:26 PM, Phil Holmes <address@hidden> wrote:
> ----- Original Message ----- From: "Graham Percival"
> <address@hidden>
> To: "Phil Holmes" <address@hidden>
> Cc: <address@hidden>; <address@hidden>; <address@hidden>;
> <address@hidden>; <address@hidden>
> Sent: Monday, March 12, 2012 7:27 PM
>
> Subject: Re: Various updates to reduce make doc output (issue 5727055)
>
>
>> On Mon, Mar 12, 2012 at 06:31:35PM -0000, Phil Holmes wrote:
>>>
>>> ----- Original Message ----- From: <address@hidden>
>>> To: <address@hidden>; <address@hidden>;
>>> <address@hidden>; <address@hidden>
>>> Cc: <address@hidden>; <address@hidden>
>>> Sent: Monday, March 12, 2012 6:18 PM
>>> Subject: Re: Various updates to reduce make doc output (issue 5727055)
>>>
>>> >--quiet shouldn't suppress warning messages, everything else looks good.
>>>
>>> The problem with this warning message is that, as part of build, you
>>> can't fix it - if you want to test converting midi with more than 5
>>> voices to lilypond, you'll get a message on screen, which is not
>>> what's wanted.
>>
>>
>> Can't you redirect the midi2ly call to a log file?  If a test is
>> deliberately checking that a midi file with more than 5 voices
>> should produce a warning, then we _want_ that warning saved to a
>> logfile so we can check that the warning doesn't go away.
>> Conversely, if we don't want that warning, then it's good to save
>> it in a logfile so that future programmers can see the problem
>> easily.
>>
>> - Graham
>
>
> 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



reply via email to

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