Re: Using -Werror in CFLAGS for a debian package build
(note: this message quotes from multiple mails by different people)
Wouter>First and foremost, I do not believe that setting -Werror in a
Wouter>debian/rules file is the best way to maintain a package; -Werror is a
Wouter>development option which should not be used in a release build (which a
Wouter>Debian package is). When a package sets -Werror in its debian/rules
Wouter>file, it *will* FTBFS when the default compiler is changed, while not
Wouter>necessarily breaking the package itself. I don't think it adds value.
The thing is that there are some warnings that really SHOULD be errors as
code that generates them is almost certainly wrong. Generally a build failure
is less serious than a subtuly broken package.
A package maintainer could try and identify such warnings individually
but I don't think many maintainers would be willing to go to that effort.
Maybe what is really needed is a -Werror=serious or similar option that
turns the worst warnings (stuff like converting a pointer to/from an
integer of the wrong size, incompatible implicit declarations and other
stuff that indicates something is SERIOUSLY wrong) into errors while
leaving minor warnings (things that really just indicate that the code
could do with a little cleanup) as warnings.
Russ>I was a bit dubious about it as well, for the reasons you state, but
Russ>please note that GCC 4.6 introduced a major new warning about set but
Russ>unused variables and, so far, every large or medium C code base that I
Russ>have has had at least once instance of that warning. And I'm usually
Russ>pretty picky about such things.
Russ>
Russ>If -Werror had not been disabled for this warning, my guess is that nearly
Russ>every package using -Wall -Werror not previously tested with 4.6 would
Russ>FTBFS.
Is this really THAT big a deal? Is it really worth making dubious changes
to build dependencies (gcc in this case but a similar saga is going on with
dash) to temporarlly hide (and therefore make harder to fix) FTBFS bugs that
are usually trivial to fix in the package that suffers from them (worst case
you can just change the cflags in this case or set CONFIG_SHELL in the
dash/configure case.
Yes it may mean some packages may need a sourceful nmu rather than a binnmu
to transition but is that really such a huge deal?
Reply to: