[Python-Dev] Windows build - fixing compile warnings before VS2010

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