Author db3l
Recipients db3l, jeremy.kloth, jkloth, miss-islington, pablogsal, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2018-12-10.22:35:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1544481338.11.0.788709270274.issue35433@psf.upfronthosting.co.za>
In-reply-to
Content
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 pick a default.

On my Win8/10 builders, I don't have an SDK that matches anything in the new checks (10586, 14393, 15063), but instead just have a single later (16299) version installed.  The Win7 buildbot does, however, also have an earlier 15063.

So what happens if none of the checked versions exist?  Am I correct that it'll enforce trying to use the minimum (10586) which won't work on my Win8/10 workers since it doesn't exist, while the default behavior to just use the SDK I have would be fine

Or is the build tool supposed to ignore the missing SDK and still use a default if later?

It seems to me the older default of letting the build tool apply its own defaults if no known matching SDK is found is better than specifying a possibly missing SDK, but obviously the older default caused an issue in Jeremy's original case.  And since the prior behavior was just to try to avoid the build tool from defaulting to too old an SDK, another solution to problems in that case might be to remove the oldest SDK, thus moving the default forward.
History
Date User Action Args
2018-12-10 22:35:38db3lsetrecipients: + db3l, paul.moore, vstinner, tim.golden, jkloth, jeremy.kloth, zach.ware, steve.dower, pablogsal, miss-islington
2018-12-10 22:35:38db3lsetmessageid: <1544481338.11.0.788709270274.issue35433@psf.upfronthosting.co.za>
2018-12-10 22:35:38db3llinkissue35433 messages
2018-12-10 22:35:38db3lcreate