Zachary Ware added the comment:
We've introduced enough new warnings in the past 3 years that this is not
viable at this point. If we decide we want warnings in the compile stage to
set the whole build to warnings, we can open an issue in
Tim Golden added the comment:
Sounds good to me. It's really a question as to the point where
practicality beats purity...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21411
___
Steve Dower added the comment:
I think we should fix all the warnings, but turning this on is a great way to
make the build bots red often. I believe they already go yellow for warnings,
so people are somewhat informed, but I don't think we want to be more
aggressive than that.
Also, I know
Zachary Ware added the comment:
Steve Dower added the comment:
I think we should fix all the warnings, but turning this on is a great
way to make the build bots red often.
That is the obvious downside. On the other hand, we do have a very old open
issue (though I don't have the number handy)
Zachary Ware added the comment:
This has been complicated by the migration to VS2015, which added a bunch of
new warnings. Obviously we can't enable this now without either fixing all the
warnings (unlikely, I think; most of them are just about shadowing vars) or
disabling particular ones.
Tim Golden added the comment:
I'm at least +0.5 on this: I rather like the idea of forcing these things out
into the open.
The reason I'm not +1 is the danger of relatively benign or trivial
warnings-turned-errors getting in the way of real, possibly critical,
development.
--
New submission from Zachary Ware:
Python 3.4 and 3.5 both compile without warnings on 32-bit Windows, so we
should turn on Treat Warning as Error (/WX option to cl.exe). Setting that
property in pyproject.props sets it for all projects, and the setting does not
affect Makefile projects so