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


From: Graham Percival
Subject: Re: GOP-PROP 5: build system output
Date: Fri, 8 Jul 2011 14:00:46 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, Jul 07, 2011 at 01:16:21PM +0100, Graham Percival wrote:
>     * We do not change the output of make, make doc, or any of the
>       other make commands - this is the default.
>     * We use the variable QUIET_BUILD to signal to the make system
>       that we want the minimum of progress output visible on the
>       terminal, with all other output going to logfiles

I think we should use logfiles by default -- actually, we should
use logfiles exclusively -- and then display bits of logfiles if
that seems helpful in debugging problems.

That said, I do not think that we should hide the ((make output)).

In other words:
- all output from make(1) should be be on the console.
- all output not from make(1) should be in logfiles.
- all output from make(1) might be saved to a logfile in addition
  to being on the console, if we can find a sensible file to
  put it in.

>     * Wherever possible, stderr output should go to *.err.log and
>       stdout output to *.log

I'm personally not wild about the difference in length between
.err.log and .log... but I also think that the suggestions that we
combine those anyway are certainly worth considering.

>     * Running (for example) make -s QUIET_BUILD=1 doc should give
>       the occasional progress message to indicate where it has
>       reached in the build process, but a such a rate that it’s
>       easy to read and a volume that allows the user to see the
>       top of the output in terminal

Disagree.  We don't need occasional progress messages; the only
case that it might have been useful was caused from a lack of
communication.  Once people know how things go, they're not
useful.

>     * Ideally, running (for example) make -s QUIET_BUILD=1 on a
>       build that fails should make it easy to see the file causing
>       the build to fail. 

I think we should omit the "-s QUIET_BUILD=1" from that sentence.
It should always be easy to see why a build fails.

Cheers,
- Graham



reply via email to

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