This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients jdemeyer, paul.moore, steve.dower, tim.golden, zach.ware
Date 2019-03-27.20:40:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1553719240.83.0.501834360897.issue36448@roundup.psfhosted.org>
In-reply-to
Content
So an important aspect of the "fix" is that this message only appears after the fix has been applied. Anyone running into this locally has already updated those files, and just needs to "git add -u" to include them in their next commit. (Unfortunately, MSBuild has no reasonable way to retrigger a build it has already completed, since that introduces cycles into its dependency resolution.)

The problem here is that when a non-Windows developer sees this error in CI, it's not clear what *they* should do about it.

The current text is: "@(_Updated->'%(Filename)%(Extension)',', ') updated. You will need to rebuild pythoncore to see the changes."

The PR adds: "You may also need to run 'make regen-all'."

I'd propose adding "%0D%0A%0D%0AIf you are developing on another platform, try make regen-all and commit the updated files"

(The %0D%0A's at the start add newlines to the output for readability.)

As an aside, I thought we had a merge hook to check this on Travis? Why didn't that trigger? There's no reason why any of our CI platforms should let you build with out-of-date frozens, so it's a bit of a shame to blame the Windows build for doing its job properly :)
History
Date User Action Args
2019-03-27 20:40:40steve.dowersetrecipients: + steve.dower, paul.moore, tim.golden, zach.ware, jdemeyer
2019-03-27 20:40:40steve.dowersetmessageid: <1553719240.83.0.501834360897.issue36448@roundup.psfhosted.org>
2019-03-27 20:40:40steve.dowerlinkissue36448 messages
2019-03-27 20:40:40steve.dowercreate