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
