[issue35433] Correctly detect installed SDK versions

2018-12-11 Thread Jeremy Kloth
Jeremy Kloth added the comment: All the Windows 3.6 windows buildbots are happy! Thanks to all! -- status: open -> closed ___ Python tracker ___

[issue35433] Correctly detect installed SDK versions

2018-12-11 Thread STINNER Victor
STINNER Victor added the comment: The 3.6 change broke the compilation 2 Windows buildbots: Jemery Kloth is investigating the regression: https://github.com/python/cpython/pull/11009#issuecomment-445985774 -- ___ Python tracker

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: Ah, got it (and see the pipelines comment by Steve). Jeremy, I suspect you might actually be able to restart the most recent 3.6 builds on my builders since you were the committer. It changed in Sep to only allow python-core users and the "owner" of the

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Jeremy Kloth
Jeremy Kloth added the comment: > Oh, it's not the installation itself, I'm just wondering if allowing a newer > version is ok too? The original PR (included in 3.7, 3.x) uses the latest discovered SDK, but Steve stated that that logic broke the Pipelines build, so I reworked to PR to just

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: Oh, it's not the installation itself, I'm just wondering if allowing a newer version is ok too? Of course, it doesn't preclude expanding the build script in the future, so I've installed 15063 to both Win8/10 workers. I don't currently have access to restart

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Jeremy Kloth
Jeremy Kloth added the comment: Well, if VS2015 is installed, the simplest way to have the required SDK(s) is to go to Control Panel -> Uninstall -> Microsoft Visual Studio (Community) 2015 Click Modify. Expand "Windows and Web Development" Expand "Universal Windows App Development Tools"

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: Hmm, VS2015 started as a full installation (with UI), probably right from its initial release. The build tools only installation (v141) is for VS2017. Best I can tell I'm at update 1 - my update version in the registry is 14.0.24720 (plus I have a .1

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Jeremy Kloth
Jeremy Kloth added the comment: I forgot to mention that the presence of UseWindows81SDK in the build log indicates that the Build Tools are at most at version 1.2 (included with VS2015 Update 1) which should still work (it's what I tested against), but the difference may be the standalone

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Jeremy Kloth
Jeremy Kloth added the comment: A quick look at the good build log does indicate that the 8.1 SDK was being used (vars UseWindows81SDK=true and WindowsTargetPlatformVersion=8.1) which is the default behavior for VS2015 if a matching (from python.props) Win10SDK cannot be found. It seems

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: (and the working log) -- Added file: https://bugs.python.org/file47986/msbuild-win10-good.log ___ Python tracker ___

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: > So before the change, the 16299 SDK wasn't being detected either, but perhaps > the 10240 one was? So I'm just confused It does seems likely that 10240 of the UCRT was being used (based on the attached msbuild logs). Howevr, the UCRT warning in the

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Steve Dower
Steve Dower added the comment: So before the change, the 16299 SDK wasn't being detected either, but perhaps the 10240 one was? That had some known issues in the debug UCRT, which is why the version gets printed out towards the end of the build. The only thing I can think of would be the

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: (sorry for the rapid updates) I'm also fairly sure that none of my workers have update 3 for VS2015. They do however all have VS2017 - but I think VS2015 still gets picked for 3.6 if both are present, right? So that's another variable, in that my workers

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: Oh, since my reading comprehension must be low today, it appears like Jeremy actually had a closer situation previously as I'm in now, with a later (not older) version of the SDK that wasn't in the list. Which is interesting, since he got an error about the

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: Well, correct me if I'm wrong, but installing 15063 would then match one of the checks, and become the selected SDK, so be expected to work fine, right? I think (not sure) that the issue with my Win8/10 workers is they only have the later 16299. So in that

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Steve Dower
Steve Dower added the comment: Both io.h and stddef.h are from the UCRT, which *may* go through a different detection process than the rest of the WinSDK. That might be the cause. The "didn't find any supported SDKs" behavior is to try and use the earliest, which should fail, but all the

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Steve Dower
Steve Dower added the comment: I'm also looking at it, so please don't revert it just yet. I just installed 10.0.15063 onto my dev machine to test another 3.6 fix and it worked fine, so perhaps there's an option that is off here? -- resolution: fixed ->

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread David Bolen
David Bolen added the comment: I'm not that familiar (ok, at all) with the build process configuration, but in looking at the changes to python.props, it appears to now enforce the minimum in the build process regardless of whether it is found, whereas before the build tool was allowed to

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: This commit broke the following (at least) the buildbots: https://buildbot.python.org/all/#/builders/38/builds/751 https://buildbot.python.org/all/#/builders/31/builds/719 can someone work on a fix? Otherwise we would have to revert the commit per our

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Steve Dower
Change by Steve Dower : -- resolution: -> fixed status: open -> closed versions: +Python 3.6 ___ Python tracker ___ ___

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread Steve Dower
Steve Dower added the comment: New changeset f04cc5fc0d2f644cccb57543aae487ee30091924 by Steve Dower (Jeremy Kloth) in branch '3.6': [3.6] bpo-35433: Properly detect installed SDK versions (GH-11009) https://github.com/python/cpython/commit/f04cc5fc0d2f644cccb57543aae487ee30091924

[issue35433] Correctly detect installed SDK versions

2018-12-10 Thread STINNER Victor
STINNER Victor added the comment: I reopen the issue since https://github.com/python/cpython/pull/11060 for Python 3.6 is still open. -- resolution: fixed -> status: closed -> open ___ Python tracker

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread Jeremy Kloth
Jeremy Kloth added the comment: I've added a PR for 3.6 using a different methodology for finding the available SDK. Without some change, my buildbot will continue to stay in the red (for 3.6). It does not the the highest SDK currently (previously?) listed the hard-coded list. It has the

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread Jeremy Kloth
Change by Jeremy Kloth : -- pull_requests: +10294 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread miss-islington
miss-islington added the comment: New changeset c83ec055a09137e4b24f70e3bb5f887dc0ae6e8e by Miss Islington (bot) in branch '3.7': bpo-35433: Properly detect installed SDK versions (GH-11009) https://github.com/python/cpython/commit/c83ec055a09137e4b24f70e3bb5f887dc0ae6e8e -- nosy:

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread Steve Dower
Steve Dower added the comment: Not making this change for Python 3.6, as that apparently breaks with the latest SDK (seen in the Pipelines build). So we'll leave 10.0.15063.0 as the maximum version for that - it's about to go into security mode anyway, and we don't rely on anything from the

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread Steve Dower
Steve Dower added the comment: Thanks for being thorough. I've merged the change now. -- assignee: -> steve.dower resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread Steve Dower
Change by Steve Dower : -- pull_requests: +10293 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread miss-islington
Change by miss-islington : -- pull_requests: +10292 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread Steve Dower
Steve Dower added the comment: New changeset f46eccd0ffe65333035c3820886295b71c41ab6e by Steve Dower (Jeremy Kloth) in branch 'master': bpo-35433: Properly detect installed SDK versions (GH-11009) https://github.com/python/cpython/commit/f46eccd0ffe65333035c3820886295b71c41ab6e --

[issue35433] Correctly detect installed SDK versions

2018-12-09 Thread Jeremy Kloth
Jeremy Kloth added the comment: Sorry for the delay, but I wanted to get an environment that still had an older VS2015 install to test against. VS2015 prior to Update 3 use a different heuristic to determine the SDK version for building. I've made the following changes: - version checking

[issue35433] Correctly detect installed SDK versions

2018-12-08 Thread Steve Dower
Steve Dower added the comment: Did you see my comment about converting the version numbers to System.Version before comparing? (I didn't know it could be done the first time I looked :) ) -- ___ Python tracker

[issue35433] Correctly detect installed SDK versions

2018-12-08 Thread Jeremy Kloth
Jeremy Kloth added the comment: Not to be impatient or anything, but this change is keeping my buildbot from being useful. Would it be possible for someone to merge as it has already been approved (msg331263). -- ___ Python tracker

[issue35433] Correctly detect installed SDK versions

2018-12-07 Thread Jeremy Kloth
Jeremy Kloth added the comment: > Is it a warning or an error? What is the warning/error message? What is your > buildbot? It is a compiler error as you point out below (with message). By buildbot is: https://buildbot.python.org/all/#/workers/12 > Right now, it seems like only "AMD64

[issue35433] Correctly detect installed SDK versions

2018-12-07 Thread STINNER Victor
STINNER Victor added the comment: After I reverted bpo-34977 change, most Windows buildbots are back to green. > In the process of eliminating compiler warnings on my buildbot, I needed to > update VS2015 to the latest toolset (VS2015 Update 3). This in turn now > causes an error due about

[issue35433] Correctly detect installed SDK versions

2018-12-07 Thread Jeremy Kloth
Jeremy Kloth added the comment: Sorry Victor, I should have added more context when I nosy'ed you to this issue. Since you seem to be the "buildbot keeper" as of late, I wanted to give you a pointer to the reason for my failing buildbot. Which, as I surmised, is failing compile due to the

[issue35433] Correctly detect installed SDK versions

2018-12-07 Thread Steve Dower
Steve Dower added the comment: No, it just automates something that's been manual for a while. Installing VS 2017 on build bots is still a manual process ;) -- ___ Python tracker

[issue35433] Correctly detect installed SDK versions

2018-12-07 Thread STINNER Victor
STINNER Victor added the comment: Is this issue related to bpo-34977: Add Windows App Store package? -- ___ Python tracker ___ ___

[issue35433] Correctly detect installed SDK versions

2018-12-06 Thread Steve Dower
Steve Dower added the comment: Looks good to me. I can't apply tags from my phone, apparently, so someone else will have to merge and mark the backport versions. -- ___ Python tracker

[issue35433] Correctly detect installed SDK versions

2018-12-06 Thread Jeremy Kloth
Change by Jeremy Kloth : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35433] Correctly detect installed SDK versions

2018-12-06 Thread Jeremy Kloth
Jeremy Kloth added the comment: Also, my buildbot *should* fail until this change is merged. -- ___ Python tracker ___ ___

[issue35433] Correctly detect installed SDK versions

2018-12-06 Thread Jeremy Kloth
Change by Jeremy Kloth : -- keywords: +patch pull_requests: +10243 stage: -> patch review ___ Python tracker ___ ___

[issue35433] Correctly detect installed SDK versions

2018-12-06 Thread Jeremy Kloth
New submission from Jeremy Kloth : In the process of eliminating compiler warnings on my buildbot, I needed to update VS2015 to the latest toolset (VS2015 Update 3). This in turn now causes an error due about not having the required version of Windows SDK installed. It seems that the