* John Calcote wrote on Fri, Apr 11, 2008 at 11:18:48PM CEST: > 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.
Redirecting stdout to /dev/null typically does not hide the warnings, they typically show up on stderr. > 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. I can't understand why people do edit-compile-test cycles without having compiler output be post-processed by their editor. It works with all decent unix editors, and it's even more comfortable than not having to go through the verbose output with your eyes. The other problem I have with Linux style build output is that if I ever get a bug report showing a build failure using that style, i.e., the reporter does not post the failing command line, then that bug report just lost half its value, by requiring yet another email roundtrip of questions. Cheers, Ralf
