Re: Code coverage report for groff 1.24.0pre -- thanks, gnulib!

"G. Branden Robinson" <[email protected]> Sun, 18 Jan 2026 16:15:12 -0600
Newsgroups	gmane.comp.lib.gnulib.bugs,gmane.comp.printing.groff.general
Message-ID	<20260118221512.dwgs3j34gioio3te@illithid>
Hi Simon,

At 2026-01-18T13:02:40+0100, Simon Josefsson wrote:
> "G. Branden Robinson" <[email protected]> writes:
> > At 2026-01-17T10:39:05-0800, Collin Funk wrote:
> >> "G. Branden Robinson" <[email protected]> writes:
> >> > In groff, we don't use GNUMakefiles--we try to use portable Make,
> >> > and have largely succeeded.  If *BSD makes have gotten current
> >> > with POSIX 2024, they may even be able to run these targets.  The
> >> > most exotic thing I see is the `?=` macro definition operator.

Which, I should note, is POSIX 2024-kosher, as are _many_ other Make
features.

https://gist.github.com/Earnestly/29deee4f18346da6630ed1df760f1590

POSIX make is hugely improved.  You can get real work done with it.

> >> The result is that using GNU Make you will have extra targets meant
> >> for maintainers. Users using another 'make' program will still be
> >> able to build the programs, without the targets meant for
> >> maintainers.
> >
> > Right, but I want any interested person (potential groff developer)
> > in possession of a release archive (or a Git checkout) to be able to
> > run the targets.  It's up to them to satisfy maintainer-mode
> > dependencies, but I see no reason to erect further barriers to this
> > sort of investigation of the code.
> 
> It is not documented to require GNU make to use gnulib-tool etc or
> maintainer-makefile -- I think -- so doesn't bootstrapping groff and
> using 'maintainer-makefile' and use 'make -f maint.mk coverage' work
> for non-GNU make?  What's the error?

I haven't tried this, and am short on both time and courage just now.

Hurricane RC-Feedback is coming and I'm nailing plywood over all my
windows.

> Given that we couldn't find any workable maintained non-GNU make
> implementation for a common GNU/Linux distribution, maybe we really
> ought to setup a *BSD CI/CD runner that actually bootstrap build some
> projects.  I have been using a OpenBSD GitLab CI/CD runner but only
> for tarball builds.

Neat idea!

> I did work on updated Debian 'bmake' packaging, but it turned out the
> package ships a bunch of custom /usr/share/bmake/mk-bmake/*.mk scripts
> that stopped working with more recent bmake versions, and fixing those
> scripts to work was beyond what I wanted to volunteer for.  I think
> the package should be split up into just the actual bmake
> implementation, and the *.mk scripts could go into a separate package
> if someone cares about them.

That sounds like a good idea.  If current {Net,Open}BSD unbreaks the
problem I observed earlier, I'd be a strong advocate for shipping it in
Debian, as groff is a reasonably complex project and bmake otherwise has
no trouble.  Debian's "current" (read: ancient) bmake is "snakebit".[1]

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff/2026-01/msg00027.html
signature.asc (application/pgp-signature, 833 B)