[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Warchoł
Subject: Re: GOP-PROP 5: build system output (probable 3)
Date: Sun, 31 Jul 2011 10:46:35 +0200


2011/7/31 Graham Percival <address@hidden>:
> We have somebody willing to work on this stuff.  He's twiddling
> his thumbs until we get the basic guidelines down.  Of course
> there will be technical implementation problems to work out later,
> but I'm really hoping that he can start work; it's been a month!
> Are there any problems with those guidelines?  If you disagree
> with a point (or if I have not convinced you that you should
> accept the proposal), please speak up.  If you would like to add a
> point, please speak up.
> ** Proposal summary
> If there are no build problems, there should be no change to
> people’s workflow.
> If there are build problems, then it should be easier to find out
> why it’s failing.
> ** Rationale
> When the lilypond build breaks, it’s too hard to figure out why it
> broke.
> We see emails to lilypond-devel approximately once every two
> months about broken builds. On a subjective note, Graham has been
> the documentation editor since 2003, but even he cannot reliably
> pinpoint the cause of a failing doc build within 10 minutes. We
> waste a ridiculous amount of time, effort, and patience on build
> problems.
> ** Sea of output
> Before any of the current work on reducing output from make, the
> result of a "make doc" was over 500,000 lines of text. The prime
> reason for the output being so verbose is that all the processes
> that run as a result of the call to make echo their output to the
> screen, often in verbose mode. Lilypond itself produces around
> 370,000 lines of output as a result of lilypond-book building all
> the snippets.
> Much of this output can be redirected to logfiles and so the
> impossible-to-read clutter on the screen is cut out and could be
> referred to later.
> ** Proposal details
> When you run make or make doc,
>    * All output will be saved to various log files, with the
>      exception of output directly from make(1).
>    * By default, no other output will be displayed on the
>      console, with one exception: if a build fails, we might
>      display some portion(s) of log file(s) which give useful
>      clues about the reason for the failure.
>      The user may optionally request additional output to be
> printed; this is controlled with the VERBOSE=x flag. In such
> cases, all output will still be written to log files; the console
> output is strictly additional to the log files.
>    * Logfiles from calling lilypond (as part of lilypond-book)
>      will go in the relevant
>      ‘build/out/lybook-db/12/lily-123456.log’ file. All other
>      logfiles will go in the ‘build/logfiles/’ directory.
>    * Both stderr and stdout will be saved in *.log. The order of
>      lines from these streams should be preserved.
>    * There will be no additional “progress messages” during the
>      build process. If you run make --silent, a non-failing build
>      should print absolutely nothing to the screen.
>    * Ideally, a failing build should provide hints about the
>      reason why it failed, or at least hints about which log
>      file(s) to examine.
> ** Don’t cause more build problems
> However, there is a danger in this approach, that vital error
> messages can also be lost, thus preventing the cause of the
> failure of a make being found. We therefore need to be
> exceptionally careful to move cautiously, include plenty of tests,
> and give time for people to experiment/find problems in each stage
> before proceeding to the next stage.
> ** Implementation notes
> There is an existing make variable QUIET_BUILD, which alter the
> amount of output being displayed
> (
> ). We are not planning on keeping this make variable.
> The standard way for GNU packages to give more output is with a
> V=x option. Presumably this is done by increasing x? If we support
> this option, we should still write log files; we would simply
> print more of the info in those log files to screen.
> Cheers,
> - Graham
> _______________________________________________
> lilypond-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]