Hi Branden, Thanks for looking at this.
On Tue, 2026-07-28 at 14:26 -0500, G. Branden Robinson wrote: > At 2026-07-28T14:15:12+0100, Richard Purdie wrote: > > I reported some build races a while ago. It appears there are still > > some issues left and they weren't an isolated problem. I tried to > > make a simple reproducer for the original problem I ran into but > > ran into further problems. To illustrate what I saw (on a fresh > > checkout of groff from git): > > [snipping the initial Gnulib-produced header issue with which I > requested aid] Glad it wasn't just me who couldn't easily spot what was needed there! I'm curious to see what the answer is... > > make doc/groff-man-pages.pdf > > GROFF doc/groff-man-pages.pdf > > /groff/groff: error: couldn't exec preconv: No such file or > > directory > > pdfmom: fatal error: test-groff exited with status 16 > > make: *** [Makefile:19752: doc/groff-man-pages.pdf] Error 1 > > make: *** Deleting file 'doc/groff-man-pages.pdf' > [...] > Good catch. preconv(1) is certainly required, as groff_mmse(7) is in > the set of documents being read by the pipeline. > > I'll fix this for 1.25.0.rc2. Thanks! > > The foregoing is an interesting case. We don't actually need > preconv, > eqn, _or_ pic to generate "automake.pdf". > > "automake.mom"'s only non-ASCII character appears in a _roff_ > comment. > > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/automake.mom?h=1.25.0.rc1#n3 > > It uses no preprocessor tokens, either (`TS`, `EQ`, `PS`, `[`). > > Yet pdfmom(1), in an effort to be helpful I suppose, brings the full > power of its battle station to bear on poor old Alderaan. That made me smile :) > $ make V=1 doc/automake.pdf > /usr/bin/mkdir -p `dirname doc/automake.pdf` \ > && LC_ALL=C GROFF_COMMAND=test-groff GROFF_COMMAND_PREFIX= > GROFF_BIN_PATH="/home/branden/BUILD/groff-1.25.0.rc1" > /home/branden/BUILD/groff-1.25.0.rc1/pdfmom - > F/home/branden/BUILD/groff-1.25.0.rc1/font - > F/home/branden/BUILD/groff-1.25.0.rc1/font - > M/home/branden/BUILD/groff-1.25.0.rc1/tmac - > M/home/branden/BUILD/groff-1.25.0.rc1/tmac -M./contrib/mom -K utf8 -p > -e -t -wall -b -P-W doc/automake.mom >doc/automake.pdf > /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec > preconv: No such file or directory > /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec pic: > No such file or directory > /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec tbl: > No such file or directory > /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec eqn: > No such file or directory > pdfmom: fatal error: test-groff exited with status 16 > make: *** [Makefile:19555: doc/automake.pdf] Error 1 > make: *** Deleting file 'doc/automake.pdf' > > However, I have to use a groff-less chroot to reproduce this problem. > If I don't, the document build escapes from its enclosure and finds > the preprocessors installed in the host environment. > > That's not good. I meant to specifically mention that, but yes, it was one of the reasons I thought I'd better report the story rather than just a patch for part of the issue. We filter out PATH during our builds so we spot escapes more easily than most (PATH is set to a single directory of symlinks so we can specify exactly what we think is needed). > I perceive 3 independent lines of attack. > > 1. As I mentioned earlier this month, we don't need to use pdfmom(1) > _at all_ to generate "automake.pdf". > > https://lists.gnu.org/archive/html/groff/2026-07/msg00019.html > > I can take care of this in the short term for 1.25.0.rc2. > > 2. Make "test-groff" set "PATH=$GROFF_BIN_PATH" and see what, if > anything, breaks. Since "test-groff" is just a wrapper for "groff", > and "groff" builds a pipeline _only_ of programs that are produced > as part of a groff build, this _should_ work. But I know better > than to bet money on it. I'll file a Savannah ticket for this issue > and will plan to work on it early in the 1.26 development cycle. > > If it works out, it should go a good distance toward solving a > problem I think Deri observed with groff documentation artifacts > getting build not necessarily with the build's groff programs. This will certainly help. What it won't find is any a build race where something else has the dependency and therefore it sometimes builds via that but not always. One slightly tedious but effective way to check things is to script a "make clean; make XXX" iteration over all the possible make targets for the source tree and see if they all build. That would verify things currently work but still doesn't protect against regressions. It is a hard problem. We build with high -j values which means we're prone to running into issues due to that too. > 3. pdfmom(1)'s mission needs to be put on a diet.[ibid.] It seems to > have mutated into a tool with no charter except to get documents > built with brute force, multi-pass processing whether they need that > or not, throwing several preprocessors at them whether needed or > not, and, recently, sprawling beyond its initial goal of easing > production of PDF documents using the mom(7) macro package to > generating general "roff" documents, not necessarily using mom(7) > (see its `--roff`(!) option) or being produced in PDF format. > > In other words, having disposed of one Perl script called > groffer(1) in groff 1.23.0, we are metamorphosing another Perl > script into its replacement. > > Enough! > > I have some notions of a new approach but they'll need to cook a > while longer. I have no concrete timeline for working this out. Sorry to raise so many thorny issues! > > It was bad enough someone suggested we should patch groff: > > > > --- a/Makefile.am~ 2026-05-15 13:23:08.000000000 +0100 > > +++ b/Makefile.am 2026-05-15 13:29:17.053867035 +0100 > > @@ -556,15 +556,0 @@ > > -include $(top_srcdir)/contrib/chem/chem.am > > -include $(top_srcdir)/contrib/eqn2graph/eqn2graph.am > > -include $(top_srcdir)/contrib/gdiffmk/gdiffmk.am > > -include $(top_srcdir)/contrib/glilypond/glilypond.am > > -include $(top_srcdir)/contrib/gperl/gperl.am > > -include $(top_srcdir)/contrib/gpinyin/gpinyin.am > > -include $(top_srcdir)/contrib/grap2graph/grap2graph.am > > -include $(top_srcdir)/contrib/hdtbl/hdtbl.am > > -include $(top_srcdir)/contrib/install-font/install-font.am > > -include $(top_srcdir)/contrib/mm/mm.am > > -include $(top_srcdir)/contrib/mom/mom.am > > -include $(top_srcdir)/contrib/pic2graph/pic2graph.am > > -include $(top_srcdir)/contrib/rfc1345/rfc1345.am > > -include $(top_srcdir)/contrib/sboxes/sboxes.am > > -include $(top_srcdir)/doc/doc.am > > > > so that we could avoid these issues! > > That's not the "right" fix, but I sympathize. > > > https://git.openembedded.org/openembedded-core/commit/?id=9deeb7474b2586eb031e4f00a644aed9ccf8cb19 > > > > I wasn't sure if there was a better way to avoid the bits of the build > > we don't really need just to get the tools? > > We have a ticket for this, but you won't _need_ a "tool-only" build if > we can keep wrappers like "test-groff" and "pdfmom" from going hunting > for tools outside of the build environment when they're run inside it. > > https://savannah.gnu.org/bugs/?68554 I don't like carrying patches like the above, which was one of the reasons I mentioned it, so you're aware of the need and to see if there is something better we can do. I added a comment to the ticket (which ended up anonymous): """ To add a perspective from a "source distro" builder (Yocto Project/OpenEmbedded), we are currently carrying a patch which disables the contrib and doc directories during the build: https://git.openembedded.org/openembedded-core/commit/?id=9deeb7474b2586eb031e4f00a644aed9ccf8cb19 We cross compile and we disable those when we build the "native" tools variant, which is effectively our bootstrapping. I'm less concerned about perl and more interested in not spending resources building things we don't need/use. With that in mind, two configure options, --disable-contrib and -- disable-docs would be wonderful from our perspective. """ i.e. we build groff multiple times and don't always need/want docs or contrib. Being able to disable those pieces would therefore be useful to us and save everyone building this some cpu/disk/energy. I'd therefore support such configure options. Thanks for the work on groff! :) Cheers, Richard
