[Python-Dev] Buildbot report (almost July)
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
>> 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
> 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