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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel