Re: GOP-PROP 5: build system output

[Phil Holmes]

----- Original Message ----- 
From: "Graham Percival" <address@hidden>
To: <address@hidden>
Sent: Friday, July 08, 2011 2:00 PM
Subject: Re: GOP-PROP 5: build system output


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

My concern with this is that we may get a lot of people surprised and 
confused by this - "hey, where's all my usual output gone - something must 
be wrong!".  By making it as it is by default, but with the ability to 
switch off the output to the screen if you know what you're doing, we avoid 
that problem.

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

No problem with that.  It would be worth adding a statement to the CG that 
this can be hidden with a -s switch if required.

> 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

Easy to do with a redirect, either "> logfile 2>&1" to send _all_ or just "> 
logfile" for non-error output.  We could add this to the CG, too.

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

I've got no problem with combining them.  It just seemed like the "system" 
was set up to allow them to be segragated, so why not do so?

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

Disagree.  If I run a statement from the command line and *nothing* happens 
for 10 minutes or so (and it's closer to 2 hours for make doc) I assume 
something has gone wrong and try to work out what.  I can't be unique. 
People expect to see signs of progress.  You may be used to kicking off a 
make doc and going off for a quiet coffee.  I think that's likely to be the 
exception, not the rule.

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

Yeah.  Was just emphasising we shouldn't lose it under quiet conditions.

--
Phil Holmes