[Python-Dev] Buildbot report (almost July)

Terry Reedy tjreedy at udel.edu
Thu Jun 29 14:57:04 EDT 2017

On 6/29/2017 1:54 PM, Steve Dower wrote:
> On 29Jun2017 1013, Terry Reedy wrote:
>> Great work.
> Agreed. Thanks, Victor!
>> How about compiler warnings (and errors)?  When I compile on Windows, 
>> there are a boatload of orange-yellow warnings.  Some are about using 
>> a deprecated featured; some about dodgy casts; some (I presume) about 
>> other things.  Should 'no warnings' be a goal?
> Yes, I think that's a good goal. We're quickly getting there as well - I 
> just merged two contributions yesterday that should significantly reduce 
> the number of warnings.

Great.  I recompiled changes for the last day or two (about 100 c files) 
and see none. _socket aside, I presume some of those files were the ones 
you fixed.

>> I believe you once fixed some, but new commits added more.  Could 'no 
>> additional warnings' be a CI requirement for merging? I expect that a 
>> new "How to avoid compiler warnings on Windows" section of the 
>> devguide would be needed.
> This is probably not feasible without a *really good* section in the 
> devguide. I would rather have warnings in the output than global 
> suppressions, and suppressing warnings globally is the usual instinct. 
> Locally suppressing warnings can be fairly hideous and is usually not 
> portable.
> Some warnings are also complicated because of the nature of CPython. For 
> example, the socket module exposes deprecated CRT functions (on Windows) 
> directly because the API of the socket module promises to provide the 
> function directly. Changing to the safer function would break the API 
> guarantee (except sometimes it won't... hence "complicated").

Thanks for the explanation.  Does 'deprecated' mean future removal in 
ms-speak?  Perhaps after the compile, build.bat should print something like
[Ignore any socket deprecation warnings]

> Noting in PR builds that there are new warnings would be great if 
> possible. I'd be concerned about it becoming a hard requirement though - 
> I much prefer to leave the final decision in the hands of trusted people 
> and provide them enough information to make a good decision.

A robot that could scan the appveyor compile log, compare with a 
'current warnings' set, and post a comment requesting a fix and possible 
help sources would be better than leaving them unseen, which I expect is 
the current situation.

Terry Jan Reedy

More information about the Python-Dev mailing list