At 2026-02-21T22:54:56+0000, Deri wrote: > On Saturday, 21 February 2026 18:13:50 GMT G. Branden Robinson wrote: > > $ find . -name gnu.eps > > ./doc/gnu.eps > > If you are in your '/home/branden/src/GIT/groff' directory (as you > clearly are for the following two commands) thank you for confirming > the existence of the "rogue" gnu.eps sitting in > '/home/branden/src/GIT/groff/doc', as I proposed as the reason you > were not seeing the issue.
It's still an out-of-tree build, as I define it; see below. > > Hmm, so why was the `PSPIC` macro able to find the image in the > > "wrong" place? Let's delete "webpage.html" and force a rebuild, > > verbosely. > > > > $ \rm build/doc/webpage* > > You must be in-tree here - else you would receive an error. No. An "out-of-tree" build is, as I've come to understand, any build where "make" is run from a different directory than that where the "configure" script dwells. Hence the necessity to "cd" to that other place and run the "configure" script via the resolution of some directory other than ".". Whence did _you_ run "configure" from _your_ out-of-tree build? If it wasn't with the current working directory as the root of the working copy, it's out-of-tree. By my definition. I guess not yours. What do you call an in-tree build where "." doesn't contain "configure"? > > $ make -C build V=1 doc/webpage.html && echo SUCCESS > > Still in-tree? Not by my definition; observe the "-C build" option to "make". > > make: Entering directory '/home/branden/src/GIT/groff/build' > > /usr/bin/mkdir -p doc \ > > && GROFF_COMMAND_PREFIX= GROFF_BIN_PATH="/home/branden/src/GIT/groff/build" > > /home/branden/src/GIT/groff/build/groff > > -M/home/branden/src/GIT/groff/build/tmac > > -M/home/branden/src/GIT/groff/build/../tmac > > -F/home/branden/src/GIT/groff/build/font > > -F/home/branden/src/GIT/groff/build/../font -ww -b -t -I > > /home/branden/src/GIT/groff/build/../doc -P-jdoc/webpage -P-nrb \ > > -P-Iwebpage -P-Ddoc/img -Thtml -ms > > /home/branden/src/GIT/groff/build/../doc/webpage.ms \ > > > doc/webpage.html.tmp \ > > > > && mv doc/webpage.html.tmp doc/webpage.html > > make: Leaving directory '/home/branden/src/GIT/groff/build' > > SUCCESS > > For me (out-of-tree):- > > [derij@pip build (master)]$ \rm doc/webpage* > [derij@pip build (master)]$ make -C build V=1 doc/webpage.html && echo SUCCESS I can't account for that failure, except that observing that "groff-git/groff" is in-tree by your definition but "groff-git/groff/build" is not. I would say that neither is, if "groff-git" is the root of the working copy. > Which actually proves I am correct, you do have a "rogue" copy in the > source directory. Possibly left over from an in-tree build, another > good reason for dropping in-tree builds. This much is true. "doc/gnu.eps" is not tracked in git: $ git log doc/gnu.eps [no output] ...which doesn't exit with a nonzero status, for reasons that I'm sure are obvious to the giant Torvalds-descended brains that work on Git. Likewise, these... $ git status doc/gnu.eps On branch master Your branch is ahead of 'origin/master' by 7 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean $ git status -u doc/gnu.eps On branch master Your branch is ahead of 'origin/master' by 7 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean ...tell me nothing useful, not even that the file is ignored due to being in .gitignore. Which of course it is, because it has to be, as a build artifact. But that applies to an _in-tree_ build. "Really" in-tree, not a in a "build" directory that is an immediate subdirectory of the root of the working copy, which would still be in-tree per your definition. $ cat doc/.gitignore | head -n 5 # build artifacts /automake.pdf /gnu.eps /grnexmpl.ps /groff-man-pages-cover.groff Here's a golden opportunity for you or one of those Torvalds-descended big brains to tell me how I've been using Git completely wrong for several years. ;-) Git supports many, many workflows. Just, it would seem, none that is obvious to me. PEBKAC, eh? Regards, Branden
signature.asc
Description: PGP signature
