Re: Report to stdout like Linux kernel compilation does

[Bob Proulx]

Robert J. Hansen wrote:
> John Calcote wrote:
> > Hmmm. I'd have to disagree here. I carefully consider every warning I
> > see, and evaluate whether or not it represents a real problem.
> 
> Yes.  This strikes me as perfectly sane behavior.

I also agree with this.  Using reasonable judgement is a good thing
and I apologize if I gave any impression otherwise.

> Insisting on warning-free builds is not sane behavior, especially given
> just how many compilers there are out there and just how many warnings
> can be reached.

On my main two development environments it is quite easy to achieve
warning free output.  My main compiler for years was the native HP
ANSI C compiler for 64-bit HP-UX.  I almost reacted to the "There are
far more compilers in the world than just GCC" comment with "GCC?
What's that?"  I have actually found gcc to generate less warnings
about things the HP compiler would warn about.  But gcc moves forward
quite quickly and probably many of those are already improved by now.
I am not a single compiler advocate.

> Insistence on perfection is not reasonable.  Not given the staggering
> diversity of platforms, not given the staggering diversity of compilers,
> the expense of getting access to these environments, etc.

Developing with a clean build and requiring a clean build on other
systems it is built upon are two different things.  I was talking
about development.  I think it is important to keep things clean as
you go along during development.  Thinking that you will fix them all
later at some other point in time IMNHO is bad.  This is very much
like the "fixing broken windows" theory.

  http://en.wikipedia.org/wiki/Fixing_Broken_Windows

I have worked on projects with so many problems that when new ones
came along people weren't motivated to fix them.  But if the build is
clean and someone adds a new problem to it then they feel pressure to
clean it up quickly.  Valid warnings frequently point to subtle bugs
that are easily avoided but otherwise consume a large amount of debug
time.  Worse is when people don't actually fix the source of the
problem but apply a layer of workaround elsewhere because they didn't
understand the root source of a problem.

> Consider Bob's original statement, the one I was disagreeing with:
> 
> > Always build with full warnings enabled.  Always clean up
> > warnings as they are introduced.  Always keep a warning free
> > build.
> 
> I agree with the first.  I disagree with the second--some warnings are
> erroneous--and I think the third is not practical, given the number of
> different compilers and OSes in use.

Consider the statement to which I was replying:

>>> 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.

Bob