Re: -Werror incorrect

[Darin Adler <darin bentspoon com>]

on 9/12/01 6:34 PM, Michael Meeks at michael ximian com wrote:

>       I'd like to suggest that I call it correct for some of the
> following reasons:

Just for the record, my thoughts on the matter, although I'm not interested
in debating this point.

>       * autotools put a lot of effort into making building software
>         easy and portable, the use of -Werror makes it difficult and
>         non-portable again.

This is a matter of opinion. Using -Werror during development helps make the
software more portable after release, not less portable. Ignoring the errors
helps if you are the just trying to build the software, but not if you are
trying to help make the software portable. For example, there are hard to
debug problems that show up as warnings and then as subtle problems at
runtime.

>       * The breakage caused by -Werror is not obviously caused by
>         -Werror, neither is a solution ( to what is probably a
>         perfectly fine warning ) presented instead you get:
> 
>           in file sys/io.h included from a.c etc. etc.
>           warning <some banal warning>
>           Error in foo/baa/baz/
>           Error in foo/baa/
>           Error in foo/
>           Error 1 - some error happened, bad luck.

This is true about all other failures in Unix builds. -Werror is not
different in this respect. It would be even better if it was clear what you
can do.

The one thing I object to here is your characterization of the warning as
"banal". We turn off the warnings that are truly banal, and leave on the
warnings that actually matter in practice.

>       * Many newbie people build from CVS - indeed, you'd want to
>         encourage them to do so, to get good quality bug reports, and
>         introduce people to hacking. If errors such as the above stop
>         experienced hackers [1] from wanting to build software - how
>         much more, others who just see that the thing "doesn't build".

It's ironic to hear you say this, since multiple times in the last 2 years
you told me "don't build bonobo from CVS -- use releases" and I had to
patiently explain why that would be a mistake.

If errors like this really stop contributors from helping on the project,
that would convince me to get rid of -Werror. I didn't notice this problem
when working on Nautilus. People seemed to be willing to work on the project
anyway, and -Werror was not cited as a major obstacle.

By the way, this is the only point in your list I find convincing. It's
basically "if you don't do it the way we're comfortable with, we won't help
you with the project" which is the same reason I switched to C for gnome
rather than using C++. If there's a consensus that people won't help us with
Nautilus unless we give up -Werror, then I will consider giving it up.

>       * The behavior of -Werror changes depending on optimization level,
>         consequently it can work perfectly for all Nautilus hackers, but
>         not others using eg. -O2

But if you change the optimization level with CFLAGS, that has the side
effect of also turning off -Werror. This seems to work pretty well.

Perhaps you are thinking of early days on the Nautilus project when we
compiled without optimization and so didn't see the "unused variable"
warning. That problem was resolved about a year ago.

>       * The kniptions to get around -Werror, to make everything warning
>         free and fine, using odd defines and flags, etc. etc. can really
>         screw up exotic systems in strange ways.

This vague allegation makes no sense to me. I'd like to see an example of
"odd defines and flags" needed to make code compile without warnings.
Characterizing them as "conniptions" is pretty funny.

I really don't want to screw up exotic systems if I can avoid it, and if
there's something I've been doing that does that, I want to stop it. I'd
gladly turn off the warning rather than doing something that will screw up
exotic systems.

>       * Yes -Werror catches bugs, but then, simply using emacs to build
>         the tree and paging through errors with C-x ` means there is a
>         large incentive to get a warning free build, so you get to
>         real errors fast.

That's not true. Warnings in files that you aren't actively working on don't
show up, because those files are not recompiled -- unless you have some bad
dependency problems or a buggy makefile that cause you to recompile
everything all the time.

If I'm not using -Werror, when I see a warning, I need to tackle it right
away, because I might not see it again until my next full build. That's how
most warnings get in there. You mean to get back to them, but without
-Werror, the only way is to do a full build and explicitly pore over the
errors. In the gnome projects without -Werror, warnings last a long time in
the code base without anyone tackling them.

Anyway, since you had a point by point listing of your reasons to dislike
-Werror, I thought I'd respond to those. I'll stop short of making a point
by point listing of my reasons to like -Werror -- there are chapters in at
least 3 books on coding style that make the argument for it, and I don't
want to add to that oeuvre, nor prolong the debate here.

    -- Darin