[self-follow-up] In a recent message, Phong reported that groff has not been cross- compilable since 1.24.0 (any maybe for longer).
At 2026-07-22T02:35:22-0500, G. Branden Robinson wrote: > At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote: > > so alternatively we could copy the host's groff doc files over > > instead of building them. > > If _I_ were working on cross-compiling groff, that is not the solution > I would prefer--it doesn't "feel right"--but as a matter of generating > deliverable and acceptable artifacts, as noted above there should be > no difference and therefore no problem. That statement felt lame when I wrote it, but the thread was sprawling--partly the fault of my own fist-shaking digression into crappy governance of FLOSS projects--and I didn't want to postpone my reply while I struggled to figure out why my Spidey sense was tingling. Eventually the two relevant compartments of my brain got back onto speaking terms. It "feels right" to me to build groff's documentation with the target platform's compiled groff objects because, especially at the time of groff 1.22.4 and before... ...doing that was almost the only kind of acceptance test we had, which I'm defining here as an end-to-end test of groff's document production that substantially resembles the exercise of a "typical" usage scenario. There isn't really any such thing as a "typical usage"--if we ignore the usual overwhelming dominance of man pages rendered to terminals--as troff's componentization means that a variety of preprocessors and output drivers are in use in any given "run". Bertrand Garrigues wrote our first test that did anything like an end-to-end groff acceptance test; it's still there, counting the number of pages in the hdtbl examples that dump font glyphs. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/contrib/hdtbl/examples/test-hdtbl.sh.in?h=1.24.1 We may have 360+ automated test scripts by now but we _don't_ have total code coverage for all of our compiled code, even ignoring error paths. No groff program or library is even "green" (90%+ coverage) by lcov(1) metrics. Only `troff` and "libdriver.a" itself are "yellow" (>75% coverage) and only barely that. (I'm pleased to have GNU troff itself as high as that, even.) But _everything else is red_. All the preprocessors. All the output drivers--gropdf excepted, for which we have no coverage metrics because it's in Perl. So while Phong's approach--which may be what Debian and other distributors do as well, to milk maximum efficiency from slow build daemons (long live m68k!)--is wholly defensible for getting usable groff documentation into the hands of users, it bypasses a means of detecting machine-dependent problems in the C/C++ code we use to _produce_ those documents. Let me know if I'm not making sense. Phong, can you shed light on Guix's philosophy on this topic? Regards, Branden
signature.asc
Description: PGP signature
