Re: webpage.html sometimes doesn't build out-of-tree? (was: error by compiling)

"G. Branden Robinson" <[email protected]>
Newsgroups gmane.comp.printing.groff.general
Message-ID <20260222012417.urwqdm4rf3pwkpu4@illithid>
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 (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmmaWrsACgkQ0Z6cfXEm
bc66UA/+PGZhmcFHq9PnTtH8qXlDQKy9bK/zrW1zoochwBipVw2uD5Rfqj+Fkkul
9OvJFrFy6SL8aJ7DgwiqA/njLFxxw+9bHmDEkVrCX+Xzy8OYZ0pwCsljnVwsp2b8
MWXM2677Q41FcPdB1jQf6Fi8o0FUi3PSEn+AnEo4WTIgaN/NQ4hudtGLvNxqQ646
PoVWzyr71wfe/iFMVkEwd3zvzhVts/UtCZ7DDjxMPSkpeGnNyJT2mXoSEEOCQ96p
GWoE7zH3DvqN+etcw1HpYifpC9BvO4v+YY7Pfhuz2/Rfk3wA8PWrBvJbJfQVTpXD
pzkmqQqaMP4+VXMX+HnkLqR8iUAreb8S7E6+DPiEyU+U2cfMjLu2KHDy8rJfGu4B
DBqJ069GT4aAI1QRllUA5/xNqOmdJ3F1Zfv+a8wjFZ/qtWxEICeRJfjVJ2ZYsKXv
gT7sil0QqjrTXPlEy18MeFXq/2/41vq3omTs4Zhb9GVZht22oF0K3TXoO/uR40g6
AxNT/X+Xmg8ddnprT7hbbQwiwpjZ+1K2FR2C/eDR8bFb0m8X4BopbkXHzPBITTnx
fp4rC6FYrCkWlnlM64D/A4wPbZ+jIbuZ9I4vZQgJr6gzFVWv2ASzJs7g2njXzoQ3
6aB4eBvQAtuOLkFjkJ3VAs4z3F4T88HbdJgKbt7axmNpEdZxH3Y=
=ZiHk
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.