Re: Build error

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Thu, Mar 24, 2022 at 10:28:22PM +1100:

> To reproduce it, I had to do an in-source-tree build.  The problem
> arises in the "install" target.  I _always_ build in a separate "build"
> subdirectory, and apparently "make distcheck" always does too, and that
> is how this failure escaped my notice.

FYI, i regularly test both methods of building:  In order to prepare
for "make dist", i use a separate "build" subdirectory in the source
tree checked out from git because that keeps my git tree cleaner (not
totally clean though because of some gnulib tentacles).
Then, in a later step, i do the OpenBSD ports build without a separate
"build" subdirectory for three reasons: it's the default, i want both
tested, and in the temporary tree extracted form the tarball,
cleanliness does not matter.

All the same, i did not trip over this issue.  I don't know the exact
reason; maybe because the OpenBSD build disables some PostScript/
GhostScript/Font dependencies.  We cannot include those because we need
groff to be built very early in bulk builds because a small number of
ports still need it to build their manual pages, and we want to avoid
circular dependencies in the ports tree if can.

Of course, as you noticed, i'm sometimes lazy and don't do such full
builds for some time, so if you do some testing of these aspects, too,
that's probably not wasted effort.

> I've created a dummy account on my dev box so as to avoid confounding
> effects of my highly customized personal environment, and added an
> "IN_TREE" parameter to my groff-building shell script--I hope that this
> will prevent problems like this from escaping in the future.

What would you think about completely removing support for in-tree
builds and making a separate "build" subdirectory mandatory?
Wouldn't that improve reliability for everyone, reduce testing
work, and all that without having any downsides?

> I'm working on this as well as a refactor of doc/doc.am, trying to clean
> up several problems that Ingo noted.  The mutual technological animosity
> between GNU Make and BSD Make, on top of the long-standing POSIX
> commitment to an anemic specification thereof[2], is a huge pain for me
> right now.
> [2] The Austin Group is finally working on adding several new
>     least-common denominator features and clarifications for the next
>     Issue of POSIX.

I'm not a make(1) specialist but just a regular user, so take the
following with a grain of salt.  I'm not convinced that everything the
Austin Group does here improves the situation, some decisions might
confound it even further.  For example, that :::= beast you mark up with
the words "(yes, really)" made me ask our make(1) specialist Mark Espie
whether he's aware of the work you are pointing to.  He just threw up
his hands in dismay, and if i understand his reaction correctly, he is
unwilling to participate in the process of the Austin Group because he
considers it a waste of time and doesn't have so much time to waste.
The NetBSD guy who is participating puts up a brave fight, but my
persional impression is that it's quite an uphill battle.

So be prepared for make(1) to remain a serious mess for the forseeable
future: getting a bit better in some respects and getting even worse
in others.  Then again, groff isn't all that complicated to build, so
it can be done in a mostly portable way, no matter how anemic the POSIX
specification may be.

Yours,
  Ingo