Follow-up Comment #1, bug #68034 (group groff): Thanks for recording the issue, Dave.
At 2026-02-09T02:49:22-0500, anonymous wrote: > Date: Mon 09 Feb 2026 07:49:14 AM UTC By: Anonymous > Ingo Schwarze said (http://lists.gnu.org/r/groff/2026-01/msg00078.html): > > "I doubt that the current in-tree/out-of-tree situation makes much > sense. IIUC, the maintainer... prefers out-of-tree by a significant > margin, and rarely tests in-tree. Why, then, is in-tree the default? > > "I would even go one step further. Given that you prefer out-of-tree, > that it is objectively cleaner and better tested, why is in-tree even > supported at all? Simply deleting the code supporting in-tree and > making all builds out-of-tree naively looks like a win for everyone: > less maintenance and testing effort for you and more cleanliness and > better testing for the benefit of users." > > In a separate thread > (http://lists.gnu.org/r/groff/2026-02/msg00038.html), > Branden responded to the latter question: > > "I don't have an answer apart from 'inertia'. However, we must be > mindful of how inertia manifests. If the bits of the GNU build system > that we use generally presume and advertise support for in-tree > builds, we could be trading one pile of grief for another by breaking > that presumption, and by violating user expectations." > > So, after 1.24 is released, changing the default to out-of-tree seems > a worthwhile step, and dropping in-tree support altogether is worth > exploring. An aspect of the aforementioned inertia that I should have named explicitly when writing is the following well-known idiom... ./configure && make ...which performs a build that is, you guessed it, in-tree. That command pair has literally decades of tradition behind it. It may be 35-40 years old (as old as GNU Autoconf itself). It's appeared in countless artifacts of documentation and dead-tree published works. I'd guess that it's better known than any single fact about _groff_ itself. Therefore in full candor I should advertise that I have little appetite for tackling this task compared to most of the ~65 others that are in "Postponed" status pending review after the 1.24.0 release. This doesn't mean someone else can't work on it, but they should probably raise the issue more broadly, meaning on the "groff" mailing list and possibly more broadly, as it seems like a significant break with the practices of other GNU projects. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68034> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
