[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GOP-PROP 5: build system output
From: |
Jan Warchoł |
Subject: |
Re: GOP-PROP 5: build system output |
Date: |
Thu, 7 Jul 2011 23:03:55 +0200 |
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