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
Description: PGP signature
