grant@NetBSD.org said:
> it does make sense if the system is Linux/BSD/similar where groff
> provides tbl(1) but groff is not installed

Can we assume that groff is a superset of nroff? (Just adding
postscript output functionality, which is not needed for manpage
formatting.) So we could accept accept nroff as a replacement
where it is provided by the OS (unless groff is explicitely
required).
But there is still the "mandoc" format... this shouldn't be needed
as long as just "tbl" is used...

So if we want to keep the impact small on OSes where a "nroff" is
already present we need a variable like "USE_TBL".

> the functionality should be added to tools.mk

Before tools.mk is hacked beyond recognition we might think about
some design issues:

-tools.mk has all information about build tools at one place. This
 might have its advantages. Otoh, it adds overhead to pkgs which
 never need this functionality. Everything we add there is evaluated
 by all pkgs. groff/tbl is only needed in 5 known cases so far.
 I'm not suggesting to split it up (yet), just want to state that
 there are scalability issues.
-As things look now, some changes would be needed so that pkgs
 for tools are not installed unless explicitely required.
 Eg if tools.mk considers the OS's "awk" unusable, it will install
 gawk as pkg, whether ever needed or not.
 (This is from code inspection, never tried in reality.)
-What about a NetBSD where just the "text" subset is not installed?
 (analogously for other subsets / OSs)

It might make sense to keep "tools.mk" small, covering the "base"
subset tools only. (This might become smaller if "syspkgs" are
deployed.)
This would mean to have the logics for groff/nroff/tbl in an own
file. This could be in pkgsrc/mk, but since "groff" is the only
pkg which can provide this functionality, it also doesn't hurt
to put everything needed into pkgsrc/textproc/groff/builtin.mk.

best regards
Matthias