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. I'm leaning toward adding a "tags" target as well, to run "ctags -R" over relevant portions of the tree. I've already been using "tags" files to develop groff with Vim and my personal fork of "mg". I see no reason not to help others do the same. > You can look at coreutils for an example. Though, I am not sure how > well the module will work in projects using C++. Yes, I have some trepidation about that as well. :) Regards, Branden
signature.asc
Description: PGP signature
