> And how many *programmers* actually bother to check compilation logs and fix
> problems that are thrown up? If you want strict error handling then add a
> --werror option to lilypond that just says "crash on error and let make
> handle it", then those people using make can deal with the lack of debug info
> their way.
OK, if I use the -dwarning-as-error option with the example I gave previously,
lilypond will abort and not create a PDF file. From the docs
(http://lilypond.org/doc/v2.18/Documentation/usage/command_002dline-usage.en.html
<http://lilypond.org/doc/v2.18/Documentation/usage/command_002dline-usage.en.html>):
"warning-as-error #f Change all warning and ‘programming error’
messages into errors."
So the warning-as-error option causes fatal errors to really behave like fatal
errors. What does this have to do with warnings exactly?
Then there’s this page
(http://lilypond.org/doc/v2.19/Documentation/usage/error-messages
<http://lilypond.org/doc/v2.19/Documentation/usage/error-messages>):
"Error: Something is definitely wrong. The current processing step (parsing,
interpreting, or formatting) will be finished, but the next step will be
skipped.”
In the case of a parsing error, the next step would presumably be the engraving?
"Fatal error: Something is definitely wrong, and LilyPond cannot continue. This
happens rarely. The most usual cause is misinstalled fonts.”
Actually, as we’ve seen, the most usual cause would be a parsing error. And
contrary to the docs, lilypond does continue, except when given the
warning-as-error option. That’s pretty incoherent.
Sharon
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
