Re: [PATCH 4/4] New automake command line option `--silent-rules'.

[Jan Engelhardt]

On Tuesday 2009-03-10 09:02, Ralf Corsepius wrote:
>>
>> My particular question above was meant as: I am unsure whether the
>> fourth patch in the series is worth applying. 
>
> I haven't checked all details of the patches, because I consider this whole
> endeavor (adding --silent) to be adding nothing but useless bloat to cater 
> some
> people's demands, who are not able to understand the harm "silencing" does.

Not silencing has had the harm that I miss the compiler warnings amidst the
command line.

>> My current take on patch 4 is this:
>>
>> It has the chance of making silent rebuilds easy for distributors,
>
> Depends on whom you are referring to as "distributors"

(Both, perhaps.)

> Upstream maintainers (people who distribute tarballs) are interested seeing
> verbose logs, to be able to go after issues their users have.

I do have to agree.

> "Silencing" will force them to tell their users to "please disable silencing",
> your logs don't contain sufficient information.

More often than enough you have to ask them for something anyway for
another reason. The most blatant example would be a "what is the
actual problem?" in response to a bug report that is nowhere near an
esr-qualifying "smart question".

> OS vendors/distributors are interested in seeing verbose logs,
> because they typically are running build jobs in batches and
> therefore have a need to analyze their batches' logs (not only in
> case of breakdowns, but also to verify "correct operation").

So here I am as a distributor - maybe not in the scale of an entire
distro, but at least as a 3rd party contributor with packages
important for myself - when I do compile these, I have to look out
for some top three most stupidest coding errors made by - let's say,
non-gifted users - two of which are already:

        - "breaks strict aliasing"
        - "makes integer from incompatible pointer type"/
          "makes pointer from integer"

Hence - in that position that I declared I am - I am interested in the
$CC warnings so that I can fix them up (because the latter usually
means the thing will explode in my face and do undefined behavior on
e.g. x86_64 where sizeof(void *) != sizeof(int)). If need be, I can
simply pass --verbose, or whatever the flag is, if I need details
about just why $CC itself failed (e.g. unknown flag).

> [FWIW: In Fedora, we explicitly mandate verbose cmake logs for this purpose.
> One side-effect of cmake using a "silent" default: many packages suffer from
> "silent bugs".]

I do see what you mean.

Automake continues to default to the traditional verbose method, and
project developers must explicitly opt-in to have the command lines
suppress. At this point, one can argue, it is a choice the project
developers have to make, whether they get the CC line from a bug
reporter in the first go, or whether they are willing to ask back.

> There is only one group who is interested in "real silence":
> Occasional random users, who are not able to understand/parse the verbosity.

Random users are the greatest testbase, we know that since Linux,
and they are rather going to jump "hey hey look I found a warning"
when they can clearly notice it. Let me postulate that many random
users would not even recognize most of the CC line gibberish -
they are just interested in getting it to run anyhow (and if it's
that they install a precompiled package where they don't get to see
*"any"* warnings, either quiesced or not).