Re: GOP-PROP 5: build system output

[Jan Warchoł]

2011/7/7 Graham Percival <address@hidden>:
>
> A variable, QUIET_BUILD, can be set and this will reduce the
> clutter but not eliminate it. (see
> http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables
> ) This variable currently does things like adding a -q flag to the
> TEXI2PDF call ("quiet") and getting rid of the –verbose flag in
> some calls to LilyPond. However, it could be used more widely, as
> proposed below.
>
>
> ** Proposal
>
>    * 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'd make this quiet build default.  I'm a fan of making things work
nicely by default (i guess that most of the people will prefer quiet
build - if not, it should not be default ofc).  Perhaps it's partly
because i'm a noob in some areas - for example i didn't know about
QUIET_BUILD.

>    * Wherever possible, the logfiles should be put in the
>      ‘build/logfiles’ directory - which will have to be created
>      as part of configure
>    * Wherever possible, stderr output should go to *.err.log and
>      stdout output to *.log
>    * 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

Sounds reasonable.

>    * 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.

+1

2011/7/7 Matthias Kilian <address@hidden>:
> On Thu, Jul 07, 2011 at 01:16:21PM +0100, Graham Percival wrote:
>>     * Wherever possible, stderr output should go to *.err.log and
>>       stdout output to *.log
>
> Wouldn't it be better to either collect both stdout and stderr in
> the same log file or to use three log files .err.log, .out.log and
> .log, where the latter contains the combined streams? Otherwise you are
> loosing the context between the two, which sometimes may be important.

This sounds nice to me.

cheers,
Janek