On Sun, Dec 12, 2021 at 7:14 AM Zack Weinberg <z...@owlfolio.org> wrote: > > On Sun, Dec 12, 2021, at 1:10 AM, Mike Frysinger wrote: > > On 07 Dec 2021 21:58, Zack Weinberg wrote: > >> On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: > >> > This has been available since automake 1.11 released over a decade > >> > ago. Let's flip the default to enable silent builds by default. > >> > >> Please don't *ever* make this change. It is absolutely essential that the > >> default build output be verbose, else anyone who's stuck trying to debug a > >> build on a CI server that they have no direct access to is in a world of > >> hurt. > > > > people can trivially add --disable-silent-rules to their configure > > invocations. > > i really don't think this is as onerous as you make it out to be. > > I can tell you've never had this experience, or you wouldn't say that. And > probably you wouldn't be proposing this patch in the first place :-P > > There's some piece of software. You don't know how its build system works, > and the process of configuring and building it is hidden behind at least one > layer of packaging automation. It's got a bug in its build, but only on some > architecture you do not have shell access to, only some CI system that you do > not administer and whose only interface is "upload software, get back logs > minutes to hours later." It builds Just Fine on your computer. > > The logs you got back from your first attempt to build it are useless because > the equivalent of --enable-silent-rules is on by default. > > You spend anywhere between five minutes and an hour figuring out which build > system the software uses, what its equivalent of --disable-silent-rules is, > and where to poke that into the packaging automation. You throw another > build at the CI. Half an hour later you get back logs that are *still* > useless because you misunderstood where the poke goes. > > You tinker with it on your computer and get the poke into the right place and > get back logs that are not useless. You throw another build at the CI. Half > an hour later you get back logs that are *still* useless because the CI uses > a slightly different build process (think pbuilder vs sbuild) and that means > the poke is still not in the right place. > > This cycle can go on for DAYS if you're sufficiently unlucky. > > Yes, an awful lot of this is the fault of the packaging automation and the CI > in question. But Automake can't do shit about that. But what Automake *can* > do is avoid making the situation even worse, by ... sticking to what it > already does: verbose builds by default. > > ----- > > I'd like to generalize the above point a little. I saw someone (possibly > you) advocating for --enable-silent-rules by default because it makes it less > likely for actual warnings and errors to get lost amid a flood of chatter. > This is absolutely true. I use --enable-silent-rules all the time on the > software that I work on frequently, because in *that* situation the chatter > *is* irrelevant -- I already have the build environment set up correctly, I'm > not going to need to figure out why the C compiler can't find <stdatomic.h> > or anything like that. And even with compilation-mode doing the actual work > of scanning for warnings, the terse log *is* easier on my poor tired brain. > > --enable-silent-rules is good for day-to-day maintenance. > --disable-silent-rules, on the other hand, is what people want when they have > no prior familiarity with some software, and they're just trying to fix one > bug, because in that situation they may *not* have things set up right and > the build system hiding details of what it's actually doing is more likely to > be aggravating than not. > > I'm arguing that the out-of-the-box, default behavior of Automake-driven > builds should optimize for the experience of people who are just trying to > fix one bug, *not* for the experience of day-to-day maintainers. That might > sound backward but think about it. Day-to-day maintainers have the time and > the incentive to set up customizations. They have plenty of other reasons to > learn the ins and outs of the configuration process. It's *easy* to get in > the habit of typing `./configure --enable-silent-rules` instead of just > `./configure` once you know that that does a thing you like. The > out-of-the-box experience does not *need* to be tuned for regular > maintainers' convenience. Rather, it should be tuned for the convenience of > people who have never tried to build the software before and do *not* have > the time or patience to mess with the defaults.
Hi Zack, Mike and Karl, I argue that we must optimize for the vastly-more-numerous cohort: consumers who are *NOT* in the unusual position of debugging some arcane build failure whose origin is masked by using AM_SILENT_RULES([yes]). I've specified AM_SILENT_RULES([yes]) in any package I've ever tended, and don't recall having or hearing reports of significant pain due to that -- but maybe that's just my selective or limited memory. Sure, there may have been some noise back in 2009 when I made it the default in coreutils via v7.2-47-g52c4018a9, but I think we worked out all the kinks long ago. As for whether V=1 does its job, AFAIK it does. If anyone finds an instance in which it does not work, that's a bug: please report and we'll surely fix it. The argument here should be similar to why when writing any code that must last: one should write to (optimize for) the audience of readers and future maintainers, who often outnumber code-writers by an order of magnitude. The volume of 99.9%-useless noise that the current default impose on every builder is not outweighed by the benefit to the rare few who occasionally cannot easily insert "--disable-silent-rules". I can imagine that an experience like the one Zack describes is painful, but we have to keep in perspective that the default imposes what I estimate to be a far larger cost, due to the vastly-larger number of people impacted. IMHO, this discussion is about setting a sensible default. No package maintainer is forced to use the automake-specified default, and even those who invoke configure can choose their own default.
