Follow-up Comment #34, bug #66583 (group groff): Hi Branden,
On Sun, Dec 29, 2024 at 05:47:41PM -0500, G. Branden Robinson wrote: > Follow-up Comment #33, bug #66583 (group groff): > > Hi Alex, > > To lead with a summary: I partly disagree with your rants, From what I've read, you agree quite a lot, actually. > but think you > may have identified a bug--the groff developers need to be able to > reproduce it, though. And I can't. 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. > At 2024-12-29T16:14:22+0100, Alejandro Colomar wrote: >> ./configure && make is a horrible thing that can only be justified >> because computers were slower back then, and because GNU make maybe >> wasn't as portable as it is today. >> >> Commands should do one thing and do it well. Those two commands do >> half a thing and don't even do it well. > > I disagree. The purpose of a "configure" script is to probe the system > for properties upon which a source code projects depends to build (or > which it can fruitfully and optionally exercise). That can be probed within `make`. No need to run a separate `./configure`, which will get out-of-date when I upgrade the system. Here's for example how I test some compiler feature within a GNU Makefile: <https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/tree/share/mk/configure/build-depends/gcc/cc.mk#n30> CC_HAS_FFAT_LTO_OBJECTS := \ $(shell \ $(CC) -Werror -ffat-lto-objects -S -x c -o /dev/null /dev/null $(HIDE_ERR) \ && $(ECHO) yes \ || $(ECHO) no; \ ) Also, probing the system would be nice, but in reality, it does more than that. It also tries to decide what the actual build will do. For example, it sets the prefix, or other variables. I suspect this will produce broken programs in many projects: ./configure --prefix=/foo make prefix=/bar make install (Although, I must admit that the alternative isn't ideal, since you're forced to specify it twice, and must repeat it exactly: make prefix=/bar make install prefix=/bar 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. > I can't find it right now, but someone once wrote a lengthy article, or > a chapter of a book, on why the X Window System's approach (xmkmf/imake) > to self-configuration of a project's source tree was so terrible > compared to Autoconf. > > As I recall, the two most salient points were these: > > 1. You, the person building the source code of whatever project, > declared to this build system a platform identifier analogous to a > GNU target triple. A master data file inside the xmkmf/imake build > system stored lists of properties describing what was believed to be > true about the targets it knew about. This sucked because X11 > didn't have a fast release cycle and, while it was under active > development, new Unix systems (and new releases of existing ones) > were coming out all the time. So xmkmf/imake perpetually lagged > reality, and people constantly deployed it in environments it knew > nothing about. > > 2. The target-specific list of properties tended to be based on what > the OS vendor _claimed_ about their system rather than empirical > facts. Then, as now, for marketing and other reasons, OS vendors, > particularly in the commercial sector, obfuscate, dissemble, or make > outright fraudulent claims about what features their product > possesses or which bugs it has resolved. This sucked (and still > does) for obvious reasons. As in science, the only way to know for > sure what your build host supports is to empirically test it. I don't know that build system, 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. It's the other part what I dislike. >> A build system shouldn't ****ing try to guess what I want to do. A >> build system should build "all the usual stuff" always. > > 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. So, I want `make all` to build _all_ the usual stuff, not just the part that the configure script thinks my system can build. >> If my system is broken and can't build "all the usual stuff", I want >> the build system to fail. Silently not building that part is just >> broken behavior usually seen in autotools-using software. The excuse >> given by autotools people is that users usually don't know or even >> care about those problems and don't know how to solve them. My >> opinion is that it should be easy to copy that error message and >> report it to someone who knows; if the software just silently stops >> building a part, then the user might think that that's all that should >> be built, and don't even realize about the problem. > > I agree with all this but it's not obvious to me how _groff_ is failing > to adhere to the principle you're espousing. 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. >> Oh, dear, I haven't yet said what I want. Let me try. >> >> I want the build system to try to build "all the usual stuff". >> make(1) provides me with a -k flag, which allows me to continue >> building stuff even if part of the build fails. Let me handle the >> build errors how I want to handle them. Don't instruct the build >> system to guess what I want on error. Just build blindly, and I will >> use `make -k`, or `make -i`, or just `make`, depending on what *I* >> want. > > Sure, yes...again, not seeing where _groff_ is failing here. Again, not a problem in this specific bug. Just another problem that gets me mad with autotools. It should die. >> And here comes groff's bug: >> >> I expect a makefile of some project which has a binary and docs to be >> roughly like this: >> >> all: prog.info prog; >> >> prog: prog.c >> cc -o $@ $< >> >> prog.info: prog.texi ## or whatever is the texinfo way >> something <$< >$@ >> >> That way, if make(1) fails to build prog.info, I can run `make -k` to >> continue building the binary, which doesn't depend on the docs. > > Yes. Sounds good. > >> However, it seems groff's build system is more like this: >> >> all: prog.info prog; >> >> prog: prog.c prog.info ## broken dependency list >> cc -o $@ $< >> >> prog.info: prog.texi ## or whatever is the texinfo way >> something <$< >$@ >> >> Which results in being impossible to run `make -k` to get the binary. > > No, WTF. This... > >> prog: prog.c prog.info ## broken dependency list > > ...should not be the case. Where are you seeing this? 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. >>> Or, as noted above, you could just ask `make` for the targets you >>> care about, instead of elaborating the build system so that you >>> never have to give that command any arguments. >> >> No. `make -k` should be a reasonable way to build everything that >> doesn't fail, without having to know the names of the specific >> targets. If that doesn't work, it's because either you or autotools >> has done something very badly. > > I broadly agree. _If_ the targets have diligently listed their > prerequisites--nothing missing, nothing superfluous--`make -k` will > build everything that can be reasonably constructed, and nothing that > can't be. > > People throwing increasing numbers of parallel cores at the _groff_ > build in recent years have exposed missing prerequisite declarations. > I've fixed these as soon as they were brought to my attention. Colin > Watson has backported at least one such fix to the groff 1.23.0 packages > in Debian trixie. > > https://salsa.debian.org/debian/groff/-/commit/7f1b2d716c23c3cfeaf24911f7f5184dca6bbf46 > >>> I'd wager that the Automake developers aren't complete idiots, and >>> that there is a good reason for them to not govern make(1) targets. >> >> I'm sorry about the rants, and I agree they're not complete idiots, >> but they make it very painful to build projects using their software. > > I'm not going to put the Autoconf or Automake developers on a pedestal; > I think Thomas Dickey's complaints of about 20 years ago about Autoconf > illustrate how Akim Demaille in particular thickly manured the field for > an Astroturfed rebellion against Autoconf; it didn't take long for > Silicon Valley firms to smell an opportunity to annex territory to their > walled gardens while opening another front in the war against copyleft > and end-user control of computing systems, and plenty of clueless people > who struggle even to type "./configure && make" happily repeated public > relations communiqués touting the superiority of the latest alternative > to the Autotools. > > https://invisible-island.net/autoconf/autoconf.html > > A regrettable own-goal to have had such feeble release QA procedures. > > But, let's not kid ourselves. Silly Valley would have done the same > thing if Autoconf releases had been anything less than bulletproof. And > maybe even then. AL/EPL/MPL/CDDL--stand tall and fight the GNU mind > virus! Here, drink this and don't ask us where it came from. Pay no > attention to the choice-of-law provision (we'll be suing you from > Matthew Kacsmaryk's federal district court if it pleases us, heh heh > heh).[1] I wonder how many FAANG executives had Monsanto on their CVs. > >>> I would characterize my own solution... > [snip] >>> +all: $(GROFF_INFO) $(GROFF_TXT) $(GROFF_HTML) $(GROFF_DVI) $(GROFF_PDF) > [snip] >>> ...as straightforward, but I dare not say idiomatic. > >> This patch is bad. IMO. > > What about it is bad? 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. I see the first thing after touching those two files is a line saying make all-recursive which makes me suspect of these two lines: Makefile:6773:all: $(BUILT_SOURCES) Makefile:6774: $(MAKE) $(AM_MAKEFLAGS) all-recursive 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.) At this point I should mention "Recursive MAke Considered Harmful", which is defended by GNU Make's maintainer Paul Smith. Please change groff to use a single makefile (may include other makefiles, as long as there's a signle make(1) process). > No _groff.info_. No _groff.txt_. No _groff.html_. No _groff.dvi_. No > _groff.pdf_. > > So, kindly, I'd sort of like to know what you guys are hollering about > when you claim groff's Texinfo manual is being crammed down your > throats. It's not that. It's that some of autotools guesses are messing the deps (probably?). Have a lovely night! Alex > > [1] I think onf may not be American, and I know Alex isn't, so here's a > supporting reference. > > > https://harvardlawreview.org/print/vol-137/district-court-reform-nationwide-injunctions/ > > > _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66583> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
