* Russ Allbery [110724 03:23]:
> > I, personally, consider all of those warnings bugs. Well, unused
> > variables aren't problems per se, but often can give good hints where
> > there *might* be some bug.
>
> Oh, sure, I agree. But sometimes it's not a good idea to immediately
> escalate a whole
Enrico Weigelt writes:
> * Russ Allbery schrieb:
>> If -Werror had not been disabled for this warning, my guess is that
>> nearly every package using -Wall -Werror not previously tested with 4.6
>> would FTBFS.
> I, personally, consider all of those warnings bugs. Well, unused
> variables aren'
* Russ Allbery schrieb:
> If -Werror had not been disabled for this warning, my guess is that nearly
> every package using -Wall -Werror not previously tested with 4.6 would
> FTBFS.
I, personally, consider all of those warnings bugs. Well, unused
variables aren't problems per se, but often can
On Mon, 23 May 2011 at 01:44:03 +0200, Goswin von Brederlow wrote:
> Or the reverse
>
> gcc -Wformat=error
gcc -Wno-error -Wformat -Werror=format
You might also be interested in m4/tp-compiler-warnings.m4 in telepathy-glib.
Usage looks like this:
TP_COMPILER_WARNINGS([ERROR_CFLAGS],
peter green writes:
> (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 i
peter green writes:
> 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
(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
Wou
Didier Raboud writes:
> Wouter Verhelst wrote:
>
>> I was working on nbd-server upstream, and so had ran ./configure with
>> CFLAGS='-Wall -Werror', which I consider good practice when writing C
>> code.
>>
>> What I didn't notice immediately was that gcc was emitting some
>> warnings, but that
Wouter Verhelst wrote:
> I was working on nbd-server upstream, and so had ran ./configure with
> CFLAGS='-Wall -Werror', which I consider good practice when writing C
> code.
>
> What I didn't notice immediately was that gcc was emitting some
> warnings, but that the -Werror option was not honore
Le Tue, May 17, 2011 at 01:31:14AM +0200, Wouter Verhelst a écrit :
>
> What I didn't notice immediately was that gcc was emitting some
> warnings, but that the -Werror option was not honored for those
> warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers
> have decided to disabl
On Mon, May 16, 2011 at 05:04:07PM -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
>
> > What I didn't notice immediately was that gcc was emitting some
> > warnings, but that the -Werror option was not honored for those
> > warnings. Investigating turned up #615157 (Cc'd): the gcc maintaine
On 2011-05-17, Russ Allbery wrote:
> I don't like seeing us modify upstream compiler behavior in Debian this
> way, but I can understand not wanting to introduce what could have easily
> been hundreds of failures. (The problem, of course, is that those
> failures are still latent, and unless we'r
Wouter Verhelst writes:
> What I didn't notice immediately was that gcc was emitting some
> warnings, but that the -Werror option was not honored for those
> warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers
> have decided to disable -Werror for some new warnings, because othe
13 matches
Mail list logo
