Repository navigation
Backport 3.5's Windows build project files to 2.7 #68696
Description
| BPO | 24508 |
|---|---|
| Nosy | @loewis, @terryjreedy, @pfmoore, @tjguk, @zware, @zooba |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/zware'
closed_at = <Date 2015-07-16.05:42:07.736>
created_at = <Date 2015-06-25.04:26:48.543>
labels = ['type-feature', 'OS-windows', 'build']
title = "Backport 3.5's Windows build project files to 2.7"
updated_at = <Date 2015-07-16.05:42:07.734>
user = 'https://github.com/zware'bugs.python.org fields:
activity = <Date 2015-07-16.05:42:07.734>
actor = 'python-dev'
assignee = 'zach.ware'
closed = True
closed_date = <Date 2015-07-16.05:42:07.736>
closer = 'python-dev'
components = ['Build', 'Windows']
creation = <Date 2015-06-25.04:26:48.543>
creator = 'zach.ware'
dependencies = []
files = ['39811']
hgrepos = []
issue_num = 24508
keywords = ['patch']
message_count = 9.0
messages = ['245795', '245797', '245798', '245809', '245881', '245882', '245893', '246041', '246790']
nosy_count = 7.0
nosy_names = ['loewis', 'terry.reedy', 'paul.moore', 'tim.golden', 'python-dev', 'zach.ware', 'steve.dower']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24508'
versions = ['Python 2.7']
Activity
zware commentedon Jun 25, 2015
Here's the (enormous) patch backporting 3.5's project files to 2.7. It also takes care of adjusting the old project files to their new home in PC/VS9.0, and makes a couple of small adjustments in distutils.command.build_ext, FixTk, regrtest, and the Tcl/Tk tests to keep the test suite running properly. I've run a couple of builds on the custom buildbots, and at this point there are no failures that I can see any reason to blame this patch for.
I would greatly appreciate some review, or at least 'review by testing' to make sure this doesn't completely break anybody's workflow.
Terry, I'm particularly interested in your feedback since I'm pretty sure you generally build from the VS GUI, which I usually avoid doing. PCbuild\pcbuild.sln *will not* work with the VS 2008 GUI, but it should work with any other VS, 2010 or newer. If you'd prefer to continue using the 2008 GUI, PC\VS9.0\pcbuild.sln should continue to work. When using the new project files, though, this should also take care of the headache of making Tcl/Tk play the game; you shouldn't have to do anything extra to be able to use Tkinter.
Steve, I did not make any changes to Tools\msi, but I'd be happy to if it makes your job any easier.
Looking forward to your feedback,
Zach
zooba commentedon Jun 25, 2015
Feel free to fix up msi.py as much as it needs. I don't particularly understand it - I just run it :)
zware commentedon Jun 25, 2015
Do you plan to use the old project files or the new? For the new, there should be no change in Tools/msi, which would make fixing it very easy for me ;)
zooba commentedon Jun 25, 2015
I'll try out the changes when I get a bit of time today or tomorrow and decide then what I'll do.
msi.py doesn't actually build the projects AFAIK, so it's probably okay. It might try to read them to get paths though.
zooba commentedon Jun 27, 2015
Looks like the required install configuration is:
The SDK is at http://www.microsoft.com/en-us/download/details.aspx?id=8279 and contains MSVC10 and platform toolset files for both VC9 and 10. Neither VS 2008 nor VS 2013 include the VC9 platform toolset.
The VC for Python package is also not sufficient, as it doesn't include rc.exe (though I'd be surprised if the output of newer versions of rc.exe aren't compatible). I haven't checked thoroughly to see what else may be missing.
zooba commentedon Jun 27, 2015
32-bit build was fine (VS 2013 + SDK 7.1 + VS 2008), but something has gone funny with the 64-bit. Need to go AFK for a bit now, but I'll try and figure that out later today.
zooba commentedon Jun 27, 2015
64-bit build didn't work (couldn't find ws2_32.lib) until I ran the SDK Configuration utility and selected v6.0A as the default SDK. This may be because I forgot to explicitly select the 64-bit compilers when I initially installed VS 2008, but it's a worthwhile troubleshooting approach.
Still building some of the big projects now, and I have to leave it again, but it looks like everything is okay once you get past setup.
I'm +0 on this change now, and I really hope the buildbots will pick up any subtle changes in the build. We should also run as many tests as possible against existing extension modules.
zware commentedon Jul 1, 2015
Thanks for testing this, Steve! It sounds like PCbuild/readme.txt will need a significant update in the setup portion to cover the different ways to get what is needed (and to mention PC/VS9.0 as a simpler setup).
I use third-party extension modules rarely enough (and even more rarely on Windows) that I'm not sure what a good set of test extension modules would be. I'm happy to run some tests if somebody can suggest some packages for it, including ones that come with binaries and ones that require compilation.
With no negative votes standing, I plan to fix the readmes and commit this before the end of next week.
python-dev commentedon Jul 16, 2015
New changeset ca78b9449e04 by Zachary Ware in branch '2.7':
Close bpo-24508: Backport the 3.5 MSBuild project files.
https://hg.python.org/cpython/rev/ca78b9449e04