"G. Branden Robinson" <[email protected]> writes:
> Hi Collin, > > At 2026-01-17T10:39:05-0800, Collin Funk wrote: >> "G. Branden Robinson" <[email protected]> writes: >> > By happenstance I noticed the gnulib developers talking about how >> > they had a GNUMakefile target for generating code coverage reports >> > for you. >> > >> > 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. >> >> The 'maintainer-makefile' module doesn't depend on GNU Make for >> building programs. It copies a "maint.mk' file with the code coverage >> rules, among other checks to the repository along with "GNUMakefile". >> The "GNUMakefile" is relatively small and includes three files, >> "Makefile", "cfg.mk", and "maint.mk"; in that order. >> >> 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? 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. 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. /Simon
signature.asc
Description: PGP signature
