[MPlayer-dev-eng] [PATCH] shorten make output

[The Wanderer]

Uoti Urpala wrote:

> On Tue, 2008-05-13 at 17:45 -0400, The Wanderer wrote:
> 
>> Evgeniy Stepanov wrote:
>>> this patch makes build output much shorter and, IMO, more
>>> pleasant to the eye. Instead of long gcc command lines only 'CC
>>> filename' or 'LINK filename' is printed. The idea and the
>>> implementation are taken from linux kernel build system. It can
>>> be turned off with 'make V=1'.
>> 
>> I hate that feature of the Linux kernel build system; it's kind of
>> nice in theory, and makes no difference when everything goes right,
>> but when things are going wrong (or just when you're curious) it
>> would be nice to see exactly what the commands are, and I've never
>> before heard of a way to do that.
>> 
>> If in fact the "V=1" approach would work the same way with the
>> kernel, then that's good to know, but I"m still not sure I like the
>> idea of extending this practice to other projects.
>> 
>> Would there be any problem with having this available but disabled
>> by default - or, at least, settable via a configure option?
> 
> Of course it's important to be able to see the exact command for
> debugging, but that doesn't mean it should be shown by default. When
> you have command lines like
> 
> gcc-4.3 -I. -Iffmpeg -Wdisabled-optimization -Wno-pointer-sign -Wall 
> -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=native 
> -mtune=native -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT 
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE 
> -DHAVE_CONFIG_H -I/usr/include/SDL  -D_REENTRANT 
> -I/usr/include/freetype2 -I/usr/include   -c -o mplayer.o mplayer.c
> 
> where the part outside "mplayer.o mplayer.c" stays the same
> repeatedly showing it again for every compilation command hides more
> interesting output.

It's true that it stays the same, and that eliding it would make the
potentially more interesting other parts easier to see. But hiding it
would also hide the fact that it stays the same (since, if I'm not much
mistaken, the exact same cover-up-the-details label would be used for
every command of the same type even if the details of the command varied
in some cases), and would make it more difficult to find out what the
exact command that is being hidden is.

>> IMO this approach makes the output, not "beautiful", but 
>> "clueless-user-friendly" - and as such I find it annoying much of
>> the time. I'm not a clueless user, I don't appreciate being treated
>> as one, and I should not have to specify some obscure option to a
>> nice clean one-word command in order to avoid being treated as one.
>> 
> 
> I think this is something of a strawman argument (though you probably
>  didn't intend it as one). Why do you think verbosity levels in
> general exist? For clueless users only?

No. But verbosity levels can also be controlled.

As I said in my other mail, I would not object to having this be a
compile-time option and disabled by default, or to having it be a
configure-time option and enabled by default. I do object to having it
be a compile-time option and enabled by default, because then anyone who
doesn't want the details to be hidden has to go out of their way on
every compilation to see them, and that's quite annoying.

> I think this is good for my own use. Evgeniy's original mail also
> talked about developer use, not less clueful users. In fact all the
> people who have supported this so far have been even less "clueless
> users" than yourself, and nobody has said this would be done for the
> benefit of those clueless users.

Nobody has said that, but that is the impression I received of the
intent when I first saw this in the kernel build, and I feel that that
is the basic idea of the underlying philosophy: hide the details by
default so that the users (who in this case are also the developers)
don't have to deal with them.

It may not have been clear in my original response, perhaps in part
because it may not have been clear even to me at that point, but my
objection is not to having this feature at all; I do not object to that,
and I do see how it could be useful in development. What I object to is
making everyone who doesn't want it change how they do things, just for
the benefit of those who do want it. Implement it such that only those
who do want it, and so are motivated to make whatever changes are
needed, have to change their way of operating at all, and I don't mind
this in the least. Making it default is what I have a problem with.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.