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 loewis, steve.dower, tim.golden, zach.ware
Date 2014-07-02.20:53:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1404334389.6.0.965885311258.issue21907@psf.upfronthosting.co.za>
In-reply-to
Content
Looks pretty good. I'm happy to see more move into PCBuild - ideally, people building a Python release should never have to look anywhere else.

buildmsi.bat can probably go away completely if the buildbots aren't using it. 3.5 will eventually have a .wixproj to build the MSI and there'll be a buildrelease.bat or similar under tools/ to keep the single entry point.

As part of the VC14 change there'll be changes to the batch files, but as far as entry points go they'll still be there. I want to move most of the functionality into an MSBuild script (currently pcbuild.proj in my sandbox) since that is generally more flexible than cmd.exe, but until then this looks like a great improvement. Not quite the 'make' equivalent you have in #16895, but that will be easy to write when "make (\w+)" translates into "msbuild pcbuild.proj /t:\1".

I don't see any value in backporting to 2.7. I've got my own scripts for that which make doing a release very straightforward, and I'm happy to keep it that way. That said, the easier we make it for people to build from source, the sooner we can stop doing binary releases for 2.7.

Consider me +0.5 on taking this change, but it's only less than +1 because I'm already working on the next major iteration and so *I* don't need them.
History
Date User Action Args
2014-07-02 20:53:09steve.dowersetrecipients: + steve.dower, loewis, tim.golden, zach.ware
2014-07-02 20:53:09steve.dowersetmessageid: <1404334389.6.0.965885311258.issue21907@psf.upfronthosting.co.za>
2014-07-02 20:53:09steve.dowerlinkissue21907 messages
2014-07-02 20:53:08steve.dowercreate