[Python-Dev] Windows build - fixing compile warnings before VS2010 (original) (raw)

Brian Curtin brian at python.org
Wed Feb 22 15:58:06 CET 2012

On Tue, Feb 21, 2012 at 23:45, <martin at v.loewis.de> wrote:

Zitat von Brian Curtin <brian at python.org>:

While some effort has gone on to get the 32-bit build to compile without warnings (thanks for that!), 64-bit still has numerous warnings. Before I push forward on more of the VS2010 port, I'd like to have a clean 2008 build all around so we can more easily track what may have changed. Does that really have to be a prerequisite for porting to VS 2010? If yes, then my hopes that we can move to VS 2010 before 3.3 are falling...

Is it a prerequisite? No. I guess with this question all I'm asking is "Can I fix a lot of these warnings without someone wanting to undo them for the sake of cleaner merges or neat hg history?" I'd prefer not to take 315 warnings into a compiler change, come out with 550, and not know what potentially went wrong. In a previous company, we changed from 2008 to 2010 by upping the warning level, fixing all warnings, then enabling warnings-as-errors (I'll address this later) - the port to 2010 went nicely and we experienced a very smooth transition. Much more smoothly than 2005 to 2008.

I just cut out around 100 warnings last night in 45 minutes, so I don't plan on having this take several months or anything. If I get stuck, I'll just give it up.

While I have your attention, I'd like to throw two other things out there to follow up the above effort: 1. Is anyone opposed to moving up to Level 4 warnings?

Not sure what this means. What kind of warnings would this get us? MS says "This option should be used only to provide "lint" level warnings and is not recommended as your usual warning level setting." Usually, following MS recommendations is a good thing to do on Windows. But then, the documentation goes on saying "For a new project, it may be best to use /W4 in all compilations. This will ensure the fewest possible hard-to-find code defects."

The last sentence (but applied to old projects) says it all. Like I mentioned above, my last company jacked everything up to the highest levels and stuck with it, and I think we wrote nicer code. That's really all I can say. No metrics, no strong support, no debate. You could just say "no" and I'll probably accept it.

...take a deep breath... 2. Is anyone opposed to enabling warnings as errors?

The immediate consequence would be that the Windows buildbots break when somebody makes a checkin on Unix, and they cannot easily figure out how to rewrite the code to make the compiler happy. So I guess I'm -1.

I didn't think about that, so yeah, I'm probably -1 here as well.

More information about the Python-Dev mailing list