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

[Zack Weinberg]

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.

zw