Am Mittwoch, 15. Juni 2011, 16:22:14 schrieb Phil Holmes:
> It creates new logfiles, since there is no existing logfile. It uses the
> name of the .ly file to generate the logfile name. So - there is a file
> called key-initial.ly. Part of the build process calls lily to process
> that, and since it has a \midi{} block, a file called key-initial.midi is
>
> produced. Currently the Lily output is sent to the terminal I've added:
> > $*.log 2>&1
>
> to the end of the call. > redirects output. $*.log expands to
> filename.log (in this case key-initial.log - this expansion is a make
> feature). 2>&1 sends error and normal output to the same place.
Hmm, doesn't that defeat the whole purpose of error messages?
I mean, by this you are HIDING the error messages, too. The current problem
with the make output is that a plethora of useless progress messages are
hiding those few error messages that would be really useful to be seen.
Hiding all error messages together with the progress messages is throwing out
the baby with the bath water (as we say here in German).
To me, the whole aim of reducing the make output is to:
-) Reduce the progress messages, so that:
-) Error messages are shown more prominently,
-) While there are still enough progress messages to see the context of the
error
I.e. when a file fails to compile, ideally the output would still show the
error message and before that the progress message which file was processed
(in particular, also the path, since we have files with similar names in
different directories!!).
Cheers,
Reinhold
PS: On my server, for the nightly doc builds, I have long ago decided to pipe
the output to /dev/null, since if there is an error, I simply can't wade
through thousands of lines (since I'm doing a parallel build with CPU_COUNT=2
and -j3, the progress messages of different files are even interspersed,
making them even more useless!) to find the error. And the thousands of
progress messages also prevent me from simply sending the last ~100 lines of
the output as the result of the cron job via email, if the make command fails.
So, if the docs fail to build on kainhofer, I probably won't even notice (and
even if I do, I won't try to find the problem and fix it).
--
------------------------------------------------------------------
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
