lkml.org 
[lkml]   [2011]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3.1] kbuild: implement several W= levels
On Wed, Apr 27, 2011 at 10:25:55AM +0200, Sam Ravnborg wrote:
> > - make the W= levels exclusive
> I do not see the point in this really. This is not what most people would
> expect.
> When you ask for more you get more - not something else.
>
> We see it with verbose levels where -vv give more output than -v etc.
>
> Anyway - the important thing is to keep the relevant warnings at W=1 level.
> Which is independendt of this change.
> So consider the input and decide - I do not want to make a fuzz about it.

I know, -vv.. increases verbosity is probably part of old unix tradition
or common sense but it doesn't make much sense in this case, IMHO. When
I use this, I want to see what the most relevant warnings are, maybe
have a crack at them to fix them, and _then_ look at the less important
ones (for an arbitrary definition of important warnings).

If we do this inclusive, then W=2 dumps the, let's call it, level 1
_plus_ the new level 2 warnings, polluting the output with something
I've already seen, but only partially. And then I start to think, did
I see this one already, didn't I, which was it? By the time you enable
W=3, the output becomes pretty useless. For example, W=3 generates 190+
MB logfile here only with level 3 warnings. Now imagine all 3 levels
combined.

Dividing the output by level of importance doesn't have this problem and
is much more workable, IMHO.

But this is just my use case, it could be that I'm completely alone on
this one. I'd love to hear what other people think.

FWIW, we might even make this behavior configurable by having

make W=1o

meaning level 1 warnings only or whatever sick idea we come up with
eventually.

;-)

Thanks.

--
Regards/Gruss,
Boris.


\
 
 \ /
  Last update: 2011-04-27 13:37    [W:0.500 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site