On Sunday, 22 February 2026 07:18:59 GMT G. Branden Robinson wrote: > At 2026-02-21T13:50:16+0000, Deri wrote: > > This is a strange one!! The error occurs if you don't have the file > > doc/ gnu.eps (because PSPIC can't find it). doc.am makes it (from > > doc/gnu.xpm) but in "out-of-tree" builds it ends up in > > build/doc/gnu.eps, and not found. > > > > The regression was introduced by commit e9da162af80 (Feb 7, 2026), > > reverting fixes it. > > I should point out that this is an incorrect, or at best incomplete, > analysis.
I'm interested to know which bits of the analysis was incorrect. Given the starting point was:- GROFF doc/webpage.html pre-grohtml: fatal error: 'pre-grohtml' exited with status 4; re-run with a different output driver to see diagnostic messages And your initial analysis was to look at pre-grohtml and decide it could not happen. So was my analysis that PSPIC was causing the error incorrect? Was doc.am building gnu.eps in the destdir - is this not true? Was grohtml being instructed to look in the srcdir - where it should not exist in an out-of-tree build - but obviously did when you were testing. Was it working before Feb 7th commit, or is that incorrect. I do not comment on whether my analysis is incomplete, it was obviously sufficient to steer you onto the right track to fix the problem - particularly because, at the time, you were claiming you did not think it was a problem. You have added to my analysis the reasons why you made a mistake when changing doc.am to build webpage.html, maybe that's why you considered my analysis was incomplete. I would point out that your eventual fix was to add -I $(doc_builddir) to the make rule for webpage.html, and the part of my analysis you did not bother to quote when you accused my analysis of being incorrect:- "Exactly the problem, gnu.eps is created in $(doc_builddir) but troff's -I looks in $(doc_srcdir). Of course, in-tree, these are both the same, so it works." I know I'm just a quadriplegic spastic so can't possibly operate in the higher realms of intellectual thought, but give me a little credit if I strike it lucky. (Or is it luck). :-) > A bug (omission of an `-I $(doc_builddir)` argument to groff in > "doc/doc.am") had been in place for a long time, but was masked by the > fact that, for some years,[0] the recipe for creating "doc/webpage.html" > included a change of directory into `$(doc_builddir)`. The reason it > had worked anyway arises from two overlapping contingencies, either of > which would result in "gnu.eps" being found: (1) a build where > `doc_builddir` equals `doc_srcdir` [what _I_ term an "in-tree" build]; > or (2) a build where "gnu.eps" ends up in the current working directory, > which should always be true (due its own target rule) when the Makefile > target is changing directories _into_ the build directory. > > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/doc.am?h=1.24.0.rc > 4#n773 > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/doc.am?h=1.24.0.r > c2#n422 > It's atypical for Makefile rules to change directories for the purpose > of generating targets. > > So I took it out.[1] > > And the problem that _should_ have been revealed was masked on my system > because of the lingering (and all but hidden by ".gitignore") > "doc/gnu.eps" file in my _source_ directory, which was (roughly) your > analysis. But that was only one piece of the puzzle. Part of it, but only in so far as explaining why you kept claiming it was not a problem. The real analysis was that PSPIC was the culprit, that gnu.eps was being created in the destdir but the make rule was directing groff to the srcdir (which is why I predicted you had a "rogue" copy in your srcdir), and even pointed you at the commit to examine so that you could look at the changes which caused the issue. The analysis you added was just why the previous version worked, I did not think that was necessary to fix the problem. > One might fairly ask, does the `PSPIC` macro really go around looking in > several directories for the argument that's passed to it? How does it > know what the `-I` arguments to the formatter were? > > No, and it doesn't know. But what `PSPIC` _does_ do is use the > otherwise little-employed `psbb` request of GNU troff, which opens a > PostScript file and parses the bounding box out of it. Being a > _request_ inside the formatter, it has access to the "inclusion file > search path" that one can augment with `-I` options, and within which > the current working directory (".") is always implicit.[2][3] > > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/pspic.tmac?h=1.24 > .0.rc4#n56 > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input. > cpp?h=1.24.0.rc4#n7593 For completeness you should mention that the -I flags to groff are passed to pre-grohtml which uses them when it calls groff -Tps -I ... so it is grops which actually locates and uses the gnu.eps file. The text in troff.1 is a little misleading since it assigns the -I directory search for the \X'ps: import ...' to troff, but troff does nothing with this, it is the fact -I is passed to grops which allows the import to happen. This is different from psbb, so and soquiet, but occurs in the same sentence. > I'm exasperated by the haste with which people apply the label > "regression" and leap to advising the reversion of commits to resolve > perceived misbehavior. Sometimes reversion is proper; sometimes not. First, I never suggested you should revert, just that reverting fixed the problem, thus giving you a big fat clue where the problem was located. Now, what I mean by a regression. A change with the unintended consequence of altering previous behaviour, usually in some negative way. With this definition, I class this as a regression (unless your intention was to break the build!!). I have no problem with changes to the build process, but if the change causes stuff which used to work to no longer work. Intention is derived from the stated purpose of a commit, its no good claiming a different intention post commit when a problem is discovered. > Such conclusions can be properly reached only as the _outcome_ of > analysis. They must not substitute for analysis. > > If you meant to suggest that made the change in commit e9da162af8 with > insufficient diligence as to its risks or consequences, then I ask you > to think again. Again, see the commit log message. Not at all, I'm suggesting it was unintentional, a mistake due to inadequate analysis of why the previous code was working, and that makes it a regression in my universe. Cheers Deri > > Regards, > Branden > > [0] Seems to date back to commit 86be72236e, 7 September 2014. > > [1] Here's the full commit log message. > > commit e9da162af80d53128990a6b19237d8c8d416582c > Author: G. Branden Robinson <[email protected]> > Date: Sat Feb 7 17:04:54 2026 -0600 > > [doc]: Simplify generation of HTML with groff. > > * doc/doc.am: Simplify generation of HTML documents with groff. > > (doc/pic.html, doc/webpage.html): Stop changing directories as part of > the target receipe; instead, alter the argument to grohtml's `-j` option to > include the name of the desired subdirectory. Drop test for existence of > separate image files afterward. Since the fix for Savannah #67133 last > May, we should be able to rely on groff to exit with a nonzero status if > grohtml fails. Tested with "make check" and "make distcheck" in four > configurations: the Cartesian product of {BSD, GNU} make with {in-, > out-of-}tree builds. > > [2] troff(1): > > -I dir Search the directory dir for files (those named on the > command line; in psbb, so, and soquiet requests; and in > “\X'ps: import'”, “\X'ps: file'”, and “\X'pdf: pdfpic'” > device extension escape sequences). -I may be specified > more than once; each dir is searched in the given order. > To search the current working directory before others, add > “-I .” at the desired place; it is otherwise searched > last. -I works similarly to, and is named for, the > “include” option of Unix C compilers. > > [3] I've had a hankering to take the `psbb` request out of GNU troff and > replace with a preprocessor or unsafe-mode macro. Regardless, it > doesn't seem crazy to me to expose the inclusion search path to > macros, say via a string-valued register. Because a search path > (if any `-I` options are supplied) has separator characters--':' on > Unix hosts, ';' on Windows--such a thing would be mightily tedious > to work with at present. It's yet another macro programming task > that would become much easier if we had a string iteration request. > > https://savannah.gnu.org/bugs/?62264 > > We could then use it to write an analogue to strtok(3).
