LGTM. 2011/7/31 Graham Percival <gra...@percival-music.ca>: > 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. > > http://lilypond.org/~graham/gop/gop_5.html > > > ** 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 > (http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables > ). 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 > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel >
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
