groff
[Top][All Lists]
Advanced

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

Re: CHECKSTYLE: Report problems with a non-zero status


From: G. Branden Robinson
Subject: Re: CHECKSTYLE: Report problems with a non-zero status
Date: Wed, 2 Feb 2022 06:34:42 +1100
User-agent: NeoMutt/20180716

At 2022-01-31T00:41:09+0100, Alejandro Colomar (man-pages) wrote:
> Hi Branden,
> 
> I started using groff(1)'s -rCHECKPATCH=3 in my chessutils game suite
> (consisting of exactly 1 game right now :~).  See
> <http://www.alejandro-colomar.es/src/alx/alx/games/chessutils.git/commit/?id=5c2ec7eecf7a3a9856fa25b951bbcf473a08d002>

> As with C static analyzers, I added it to the makefile, so that I run
> `make analyze` and see if there's any problem with the code.  Ideally,
> I'll get nothing on standard error, an exit status of 0, _and_ some
> dummy files to mark the success to make(1).  If there's any problem,
> I'll get something on stderr, I'll get an exit status of something
> non-zero, _and_ the dummy files will not be created, so that make(1)
> warns me again and again.  If I overlook an error once, I'll keep
> getting it, instead of believing that it's still there.
> 
> But groff(1) doesn't error out when it finds some problematic code, so
> I'll see some shy error on standard error once, but then if I run
> make(1) again, I'll believe that everything is OK.
> 
> So, my suggestion is to return non-zero when -rCHECKSTYLE reports
> something.

That's a reasonable thing to want but it runs against the grain of how
*roff programs generally handle diagnostics and exit statuses.

I have a recommendation or two for how you should be able to get the
behavior you want.

Quoting your commit diff above...

+DEFAULT_GROFFFLAGS := -man
+DEFAULT_GROFFFLAGS += -rCHECKSTYLE=3
+DEFAULT_GROFFFLAGS += -z
+EXTRA_GROFFFLAGS   :=
+GROFFFLAGS         := $(DEFAULT_GROFFFLAGS)
+GROFFFLAGS         += $(EXTRA_GROFFFLAGS)

+$(MAN_cks): $(builddir)/%.cks.touch: $(MANDIR)/% Makefile | $$(@D)/.
+       $(info GROFF CHECKSTYLE $@)
+       $(GROFF) $(GROFFFLAGS) $<
+       touch $@

You can do the following:

+DEFAULT_GROFFFLAGS += -Msomedir -mdeadly

Where "somedir" is a convenient directory in your source tree; I'm not
sure quite where would make the most sense for you, and I didn't study
the project closely.  (Sorry, working on groff... :-| )

The next thing to do is create a file, "deadly.tmac", in that same
convenient directory you chose.

cat > deadly.tmac
.am an-style-warn
.  ds LANDMINE\"
..
.de end-of-input-macro
.  if d LANDMINE .ab found style problems; aborting
..
.em end-of-input-macro

It looks like you're using the default output device, so you don't need
to worry about the fact that continuous rendering mode already sets up
an end-of-input macro.  If you've changed your default output device
(say, with GROFF_TYPESETTER), then you need to append to the existing
one instead of installing a new one.

.am an-end
.  if d LANDMINE .ab found style problems; aborting

This should suffice to make the style warnings lethal.  The `ab` request
causes troff to exit with a nonzero exit status, which will percolate up
through groff in a way that wasn't documented until recently[1].

If you want the formatter to blow up on the _first_ occurrence of a
style problem, that's even easier.

cat > deadly.tmac
.am an-style-warn
.  ab

Does this help?

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=42c2de802928aedd12220838048881a075376e01

Attachment: signature.asc
Description: PGP signature


reply via email to

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