| 1 |
On Wed, Sep 12, 2018 at 6:55 PM Thomas Deutschmann <whissi@g.o> wrote: |
| 2 |
> |
| 3 |
> On 2018-09-12 16:50, Rich Freeman wrote: |
| 4 |
> > There is also the case where we want these warnings to block |
| 5 |
> > installation, because the risk of there being a problem is too great. |
| 6 |
> |
| 7 |
> I really disagree with that. So many devs have already said multiple |
| 8 |
> times in this thread that "-Werror" is only turning existing warnings |
| 9 |
> into fatal errors but "-Werror" itself doesn't add any new checks and |
| 10 |
> more often requires "-O3" to be useful. |
| 11 |
> |
| 12 |
|
| 13 |
This seems unlikely. If upstream is using -Werror in their build |
| 14 |
system, then they'd be getting build errors if these warnings already |
| 15 |
existed at the time they released the version. |
| 16 |
|
| 17 |
Now, I could buy that -Werror turns NEW warnings into fatal errors, |
| 18 |
due to the use of a newer toolchain, since upstream probably didn't |
| 19 |
test with that toolchain and thus wouldn't have seen the warning. |
| 20 |
|
| 21 |
If the warning only appears with -O3, and the package isn't built with |
| 22 |
-O3, then -Werror is a no-op and is harmless. |
| 23 |
|
| 24 |
But, I think there is somewhat of a legitimate point in pointing out |
| 25 |
that -Werror is in some sense just a proxy for detecting when a |
| 26 |
toolchain is being used which wasn't tested by upstream. You could |
| 27 |
accomplish the same by sticking a ton of toolchain blockers in the |
| 28 |
package. Of course, I can't imagine the toolchain team would be |
| 29 |
terribly happy about that, but if you want to avoid using newer |
| 30 |
toolchains with older versions of a package that would probably the |
| 31 |
the appropriate way to do it. |
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives