Follow-up Comment #43, bug #66583 (group groff): Hi Alex,
At 2024-12-30T01:24:39+0100, Alejandro Colomar wrote: > On Sun, Dec 29, 2024 at 05:47:41PM -0500, G. Branden Robinson wrote: >> Follow-up Comment #33, bug #66583 (group groff): >> To lead with a summary: I partly disagree with your rants, > > From what I've read, you agree quite a lot, actually. Well, I didn't want to risk dashing your hopes later. ;-) > I can't reproduce it on Devuan testing (Excalibur), which I installed > in my desktop yesterday. > > I can't reproduce it either on a Docker container with Devuan stable > (Daedalus). > > But I can reproduce it on a fully-updated Devuan stable machine (my > laptop). Even on a fresh new git clone of groff it reproduces. And > even after running `apt-get build-dep --no-install-recommends groff` > to install all dependencies for building groff. > > I'll receive a new laptop in a few days. There, I plan to install > Devuan stable again. I'll try to reproduce it there on the clean > install. I'll let you know if it reproduces there. Okay. I'll return to this point below. I have a hunch. [rearranging a bit] > I don't know that build system [imake], and don't know what I would > think of it. But yeah, the "probing the system" part of a configure > script, I like it. In my build systems, I run it as part of make(1), > so that the probing is run every time you run make(1) (it's quite fast > compared to the actual build), so that if the system gets an upgrade > between make(1) runs, the probing is accurate to the current system. I think a lot of people prefer a separate ./configure (probing) step because generally the characteristic parameters of the system don't change between that time and the subsequent `make` command, so there's no reason to spend _any_ time re-probing. I like the separation of concerns. There may also be a factor of historical inertia: Autoconf has had a configuration caching feature (one that persists between runs of the ./configure script, I mean) for a long time, but I don't know if it goes all the way back to the first releases. Those were before my time. It could be that "./configure && make" was such a famously winning formula that no one wanted to mess with it. Another factor that's tricky about incorporating probing into Makefiles is that, unless Autoconf and system vendors carry the Unix Philosophy of Everything Is a File much farther, it's hard to tell if something "configgy" is out of date. How does a Makefile know if packages on the system have been upgraded since it last probed? How does it know whether any of those package upgrades are relevant? One can indeed do what you do, and re-probe everything all the time. For me, that would likely be unsatisfactory--for projects I work on, the time spent running "./configure" is _not_ negligible. All of that said, I think you do have a point that Autoconf might have gotten a bit overloaded. The parameters of the system, like "what's my compiler?" and "how does my libc behave?" are clearly distinguishable from user decisions like "I don't want the docs". But back on the gripping hand, I can see how the line between these gets blurry in cases like, "I have both Clang and GCC installed, and I want to use <preference>". If I had a magic bullet, I'd load and fire it. > Also, the list of targets should be unconditional, and configure > shouldn't mess with them. Targets are make(1)'s business. But > usually, ./configure does change them significanty. > > It's [this] other part what I dislike. I trust you realize that you and onf are arguing diametrically opposed objectives here. He _absolutely_ wants to drive target selection from the "./configure" script. Or did. The plethora of new make(1) target names he's proposed, he might regard as a complete replacement for that approach. [I'm assuming a gender pronoun here. Let me know if it should change.] >> That _is_ guessing what you want to do. But "all the usual stuff" >> is a good guess. That's what a default make target is _for_. > > That's as much guess as I can tolerate. But that guessing should be a > one-time guess. That is, the maintainer should decide what `make all` > does, and then that should be done on every system. If the configure > script decides what's to be done based on my system, we're in trouble. I think there's a limit to that principle, one which groff hits in several respects. If I were to apply it literally, I'd have to drop from the source tree everything that exercises an optional dependency. We have so many of those that we have several _NOTICE macros to warn users about what they'll be missing because they don't have them. https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n222 https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n245 https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n321 https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n407 https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n520 https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n1729 https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n1867 I suspect Deri would be cross with me if I dropped gropdf from the groff distribution. And others would get mad if I cause the build to fail hard just because some output driver they don't use (like grohtml) couldn't be constructed. > So, I want `make all` to build _all_ the usual stuff, not just the part > that the configure script thinks my system can build. This sounds like another way of saying you want to populate the dependencies of the default target differently, overriding those that the ./configure script in its present form omits. More precisely, you want the deps of the default target to not vary, ever, and just have the build fail hard during make(1) if _anything_ won't build. That's going to be a shocking change for our users, and it's going to amount to supporting only one configuration of groff in this respect (you get grohtml, gropdf, X11, and URW font support, or you get a failing build). That's not a _horrible_ idea. I like the thought of reducing the dimensionality of the configuration space. But those knobs were put in there in the first place on purpose, because different groff user communities (mainly GNU/Linux distributors, I think), just didn't want to bother with certain prerequisites. groff's development philosophy has been to be accommodating. I suggest you pitch this change of approach to the groff@ mailing list and see what sort of response you get. I allot myself a quota of potentially user-angering changes and I prefer to spend my allocation on those that I value highly. My inclination is keep things as-is in this respect, except for reducing grohtml's dependencies by rearchitecting it (to eliminate pre-grohtml(1), mainly). But that's a long-term project. > It's not related to the bug. Just part of the rant against autotools > being brain damaged. One of the problems that keeps me thinking that > autotools should die, and be replaced by carefully written GNU > makefiles. [...] > Again, not a problem in this specific bug. Just another problem that > gets me mad with autotools. It should die. Okay. Replacing Autotools is not an objective of mine. > I don't see it in the makefiles (god save me from trying to read them). > That's what I experience in my laptop. As in, I clone the repo, then > bootstrap and configure as always (no args), then `make -j24 -k`, and > I end up with an error about docs, and no groff binary. > > Why? I don't know. When I get the new laptop soon, I'll try to > reproduce on a clean install of Devuan stable. We'll see. > > I'm also puzzled about why it doesn't reproduce on a Docker container. Okay, coming back to this. This is just a guess, but I wonder if what you're encountering is some sort of memory starvation. On the debian-devel@ list there's a recent thread about this. Long story short, parallelism in CPU cores is outrunning memory provisioning (since each core wants its own partition of RAM[?]), and since Unix has been committed to memory overcommit since the first (or at least the earliest well-known) virtual memory kernel in 3BSD, people are encountering pain. https://lists.debian.org/debian-devel/2024/11/msg00498.html https://lists.debian.org/debian-devel/2024/12/msg00092.html > That it doesn't seem to address the bug I experience, which I can only > explain as a wrong dependency somewhere. > > Since I can't reproduce it anywhere except my laptop, I've tried > something there: I touched the files that make(1) is having trouble > building, which were > touch doc/groff.dvi > touch doc/groff.pdf > > and after that, the build run just fine. A thing to know is that these are the only two targets that involve a TeX system, and TeX is _very memory-hungry_. Compared to groff, anyway. So it might be getting memory-starved. > So, some part of the build is a dependency of 'all', and other part is > 'all' itself. This is brain damage. That's causing a hidden > dependency where all of the recursive build (whatever that is) depends > on all of the BUILT_SOURCES (whatever that is). That's the bug. (Why > can't I reproduce it elsewhere? I don't know. Probably those guesses > that we mentioned before.) Before blaming groff's Automake files I'd make sure you know for _sure_ why the build is failing. > At this point I should mention "Recursive MAke Considered Harmful", > which is defended by GNU Make's maintainer Paul Smith. I'm familiar with it, and endorse it as well. > Please change groff to use a single makefile (may include other > makefiles, as long as there's a signle make(1) process). I'm not sure how recursive it really is in Peter Miller's sense. Here are all the matches for '$(MAKE)' that I can see: $ git grep -F '$(MAKE)' ChangeLog.120: $(MAKE) and $(MDEFINES) are used. contrib/mm/Makefile.sim: $(MAKE) -f Makefile.sub tmacdir=$(tmacdir) srcdir=$(srcdir) \ contrib/mm/Makefile.sim: $(MAKE) -f Makefile.sub tmacdir=$(tmacdir) srcdir=$(srcdir) \ font/devlj4/devlj4.am: $(MAKE) -f $(devlj4_srcdir)/generate/Makefile \ font/devps/devps.am: $(MAKE) -f $(devps_srcdir)/generate/Makefile \ 1. A ChangeLog entry. Ignore. 2. Two hits in a very old Makefile, unused by groff's build system for supporting standalone maintenance of "mm", a _contributed_ hunk of the source tree. I wouldn't be surprised if this file is bit-rotted, and since I seem to be the new mm maintainer (I'm the only person to have done a lot of work on it since Jörgen Hägg went dormant), it might be my prerogative to just rip this out. See the "Makefile.sub" reference? That's a relic of the old, pre-Automake groff build system (see groff 1.22.3). 3. Two output drivers launch make. These look like smoking guns until you realize that there are in "maintainer-mode" targets upon which nothing depends. Moreover, the Makefiles in question are shipped and installed to support users who want to generate groff font descriptions for digital fonts they may have lying around and which stock groff doesn't know about. So these Makefiles _have_ to work independently of the groff build itself. Also check this out: https://git.savannah.gnu.org/cgit/groff.git/tree/Makefile.am?h=1.23.0#n606 The _inclusion_ of the subordinate *.am files, as opposed to "cd"ing into a subdirectory and running "make" in it--essentially so that you have one big dependency tree instead of a forest of trees--is exactly the sort of solution prescribed by Peter Miller. Possibly the target name "all-recursive" has misled you. It doesn't seem to be groff's invention. Maybe it's a misleading choice on Automake's part. Just a guess. The comment at the other end of that hyperlink is pretty suggestive, too. ;-) If you're not aware of it, please read Bertrand Garrigues's paper on the use of Automake in groff. He's the person who ported us to it. It's in the source tree as "doc/automake.mom", and gets built as a PDF. > It's not that. It's that some of autotools guesses are messing the > deps (probably?). I don't think we have sufficient evidence to warrant that conclusion yet. Regards, Branden _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66583> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
