Re: GOP-PROP 5: build system output (probable 2?)

[Graham Percival]

On Thu, Jul 28, 2011 at 08:25:25AM +0200, Jan Nieuwenhuizen wrote:
> Graham Percival writes:
> 
> > You mean, like
> >   23cdda9506931d5b9a1e75ee8be8b74f9084a7c0
> > ?
> 
> Yes (I would have called the option --log).

IMO a long descriptive name is better than a short name that's
open to interpretation.  Note that --redirect-lilypond-output does
*not* save any output from lilypond-book (the python script) to a
file.  I'd expect a --log to do that.

We may well look at adding --log in the future, or else do that
redirection in the build system.

> > I'd call it 20% rather than 90%, but yes, Phil's work on
> > lilypond-book will certainly be valuable!
> 
> Assuming that --redirect-lilypond-output is used during build now,

It is not.  We are moving very slowly and cautiously to avoid
creating more problems.  --redirect-lilypond-output needs a lot
more testing, particularly stuff like .tely files including .itely
files including .ly files.

The build system has not been touched, in large part because we
have not yet decided on what the overall policy should be.

> > I don't agree.  Log files are cheap; I think we should always
> > write the logfiles
> 
> I don't get this.  Any sort of complexity added is expensive.  It must
> be written, it must be documented, it must be remembered, it must be
> maintained.  One of the biggest responsibilities as a maintainer is to
> deny most if not all `nice to have' features in favour of simplicity and
> more important things.

I submit to you that since we have 1 thread about broken builds
every 2 months, the current build system needs to change.  I think
this extra complexity is worth it.

BTW, do you consider the logging system in GUB to be unnecessary
added complexity?  I find it incredibly useful.

> Moreover, I figure that c/c++ compilation amounts to only a maximum of
> about 0% to the sea of output burden.  What are you trying to fix?

We're mostly trying to fix the doc output.  In case there is
ambiguity here, "build system output" refers to
  make doc
in addition to plain old
  make

We are trying to figure out general policies for the build system.

> Also, you are [should be] probably running c/c++ compilation in -j4
> mode; how are you going to find/determine which compile failed and
> what log file it is?  Then, you have to open the log file and tell
> your editor to go to the right location.

If we cannot clearly distinguish which log file (from -j4)
contains the error, then obviously we would simply redirect all
threads to the same log file.  I consider this a relatively minor
implementation detail; the relevant policy point is:
  "Ideally, a failing build should provide hints about the reason
why it failed, or at least hints about which log file(s) to
examine."

If a certain arrangement of log files (be that merging files,
splitting files, whatever) does a better job of bringing the error
to the user's attention, then we should use that arrangement.

Cheers,
- Graham