Follow-up Comment #17, bug #67612 (group groff): [comment #16 comment #16:] > I have a pending change to "downgrade" the two messages Dave > identifies as not really warnings to "Notices",
Excellent.
Still, I think there's a design question to ponder.
> The change in behaviour (setting an exit code on warnings) was added so that
>
> make would abort if gropdf reported a warning, at Branden's suggestion.
I think most software exits with 0 if only warnings are emitted. (This does
not appear to be addressed in the GNU Coding Standards.) I reiterate my point
in comment #1, that compiler warnings are designed to exit as success, so as
to allow "make" to continue. So I don't think gropdf should violate this
convention without good reason.
Its exit code was changed (in the commit cited in comment #1) as part of the
solution to bug #67268, which deep-dives into build-system arcana that's over
my head. So maybe there _is_ good reason here. But would it be a better
design to make the user explicitly request that warnings exit as errors?
(This is a genuine question; I'm not trying to put a thumb on either side of
the scale.)
> Also, this only affects situations where groff is used in a
> workflow where the exit status is checked, which is a subset
> of usual uses of groff - to produce a single document from the
> command line.
I encountered it producing a single document from the command line. It's just
that, when editing and regenerating a document many times, it's often easier
to set up a trivial Makefile and type "make" rather than "groff -Tpdf
filename" each time. Granted, the PDF is successfully generated, but "make"
reports a failure each time.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67612>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
