Re: [RFC/PATCH] m4: enable silent build rules by default

[Jim Meyering]

On Sun, Dec 12, 2021 at 7:14 AM Zack Weinberg <zack@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.