Hello Branden and Guix, On 2026-07-23 at 21:24-05:00, G. Branden Robinson wrote: > In a recent message, Phong reported that groff has not been cross- > compilable since 1.24.0 (any maybe for longer). > > Phong, can you shed light on Guix's philosophy on this topic?
I am fowarding this to the Guix list as well for the requested advices. Some context for the latter, groff fails to cross compile since the recent misc-world-rebuild merge that bumped it to 1.24.0: https://ci.guix.gnu.org/build/23724455/log/raw On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote: > > On 2026-07-21 at 21:48-05:00, G. Branden Robinson wrote: > > > At 2026-07-22T11:18:56+0900, Nguyễn Gia Phong wrote: > > > > Speaking of cross compilation, it has been broken since at most > > > > 1.24 as pdfmom used to build doc/automake.pdf uses test-groff > > > > instead of GROFFBIN, I think: > > > > > > In the short term, if "automake.mom" doesn't actually need > > > multi-pass formatting, then we should move it back to `GROFFBIN`. I > > > don't see any forward references; the relocated table of contents in > > > the PDF rendering doesn't count, because that's achieved by > > > PDF-level page resequencing magic. > > > > Thanks, am I understanding correctly that if multi-pass formatting > > (or any formatting at all) must be done to-be-built groff et al, > > it has to be disabled under cross-compilation? > > I _think_ that's correct. (Cross compilation might have not worked when Guix carried groff 1.22.4 for a different reason, we just don't seem to keep good track of targets other than Linux on amd64: https://ci.guix.gnu.org/build/23648045/log/raw) On 2026-07-23 at 21:24-05:00, G. Branden Robinson wrote: > 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. Just for clarity, "Phong's approach" here refers to At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote: > alternatively we could copy the host's groff doc files over > instead of building them. and is merely a suggestion and not done for Guix. Best wishes, Phong
signature.asc
Description: PGP signature
