On Fri, Apr 11, 2008 at 3:00 PM, Bob Proulx <[EMAIL PROTECTED]> 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
