groff cross-compilation and acceptance testing (was: Git snapshot tarballs, multiple-pass formatting, and pdfmom)

--nbwy2mxtaxlxvnyw
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: groff cross-compilation and acceptance testing (was: Git snapshot
 tarballs, multiple-pass formatting, and pdfmom)
MIME-Version: 1.0

[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=E1=BB=85n Gia Phong wrote:
> > so alternatively we could copy the host's groff doc files over
> > instead of building them.
>=20
> 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...

=2E..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/example=
s/test-hdtbl.sh.in?h=3D1.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

--nbwy2mxtaxlxvnyw
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmpizM4ACgkQ0Z6cfXEm
bc4/hQ//XrrkcyfN9BhqDK0RPCok25X0VMEb2lFPIOGaGDJaVW5ZfMauE0Je6FCZ
kVOEsYCHYXMCejyVih41sQRp6pszC1vkZ91GUiRW6veS8lqcyu7p209C8aS1ZLot
+PWBx4RWXZjbWnWCqH9305qiFEbxpd2mJ75eRCLTYMu5ABfNab31JjuwBgq5/M2o
3lIgyMzgm+Fzb1be/k6OsxcWcMICn2kXidtXQRW7RJChBVXi6l6GqJMnfFVKaQmv
R1tYLV1ruuV+jKaxDKQm2rZ39ywra8Gg4GrxQDYA/0RjGXiFQeG5fk6ROmbylq2b
3IcI66dXBZ+IQy0TN8dWN6OSRPyBh8XY3PLXhM/ASTtCzD/bXVl7gkyk9GuFe+Rt
Srism4G6SVqB4kfkPNZMRoMamncWOkFylBT41l072wzuJboS7WXG1R1cEFlTVMXD
sFFDq1CjB1abb0bY2R3JBdUiLMYFlvAaOtrvihHwiSOexlu9AKoeFKyrc69Hqzbc
amp1wQXP6jH1ef4WAfnX28oujH/QZB2NhplE/hKAIBDDWEXvtKJl6peEfkN8QYRt
mixmA7M0XAcOGfpUO8C6JmewntdjC+53uezElaC8PzpS/SygfNiNn3KipTX2/FJb
KiwnkJkyQWpSy7sxjt9Oel23l7P0Bn5fyoMHUbffK2IPUHoKcfE=
=QkJM
-----END PGP SIGNATURE-----

--nbwy2mxtaxlxvnyw--