Re: Report to stdout like Linux kernel compilation does

[John Calcote]

On Fri, Apr 11, 2008 at 3:00 PM, Bob Proulx <address@hidden> wrote:
>  >>> When you want to clean up the warnings (usually something done near
>  >>> the end of a development cycle), you simply build with stdout
>  >>> redirected to /dev/null when you run make a few times, and you'll
>  >>> see the warnings appear, because they're output to STDERR, not
>  >>> STDOUT.
>
>  Since you disagree with my statement challenging this then does that
>  mean that you agree with the strategy I was challenging?  That is,
>  don't check the project build warning status until you are "near the
>  end of a development cycle" and _then_ start to address warnings?  I
>  am sorry but that type of strategy triggers an immune response in me.
>  I strongly believe this is not a good strategy and am not shy about
>  stating my opinion on it.  Don't let broken windows accumulate.  Fix
>  broken windows as you go along so that the project is always in as
>  good of a state as possible all of the time.
>
>  Every time I compile on a new platform I look at the warnings
>  generated.  If my native compile environment isn't smart enough to to
>  generate a valid warning but another platform is smart and generates a
>  previously unknown valid warning then I am not going to ignore it.
>  Every new environment that my code reaches almost always teaches me
>  something useful about my code.
>

I'm sorry - I was a little confusing here. I don't actually work this
way either. I'm a stickler for details, and I can't really abide
warnings being left around for weeks or months - it's the
Type-A'ed-ness in me or something. Anyway, what I meant was that my
development cycles are fairly short - I might not get around to
checking for warnings (by redirecting stdout to /dev/null) for a few
days, so I might let a few warnings go for a week (or less), if I'm
busy working on a task.

But for this very reason, I think it's a good idea to have clean
output. I've heard all the arguments before about not being able to
see the cause of the warning because your command line is obscured by
a pretty-printing build system. I like to see full output, AFTER I've
discovered there's a problem. In which case, I'd then go to the build
log file to see the FULL output. I just don't see why we have to watch
complete build information go by with a build that has no warnings or
errors - which is supposed to be the usual case - it's the exceptional
case where you need to see full output.

As far as setting up your editor to take you to the next warning or
error on command - now that's a cool idea - I love how this works in
the M$ IDE on my Windows projects.

John