-
-
Notifications
You must be signed in to change notification settings - Fork 29.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Visual Studio 2010 #57419
Comments
Python for Windows is currently compiled with Visual Studio 2008. It would be great to be able to compile Python with Visual Studio 2010:
This is the parent issue. I have various patches to achieve that and I will try to open one issue by patch. I may also run a builtbot using that compiler. |
We can make Python compile with Visual Studio 2010, but it will not be the platform Python is released on, it would be optional while 2008 stays the release target, at least through Python 3.3. In Python 3.4, we may re-evaluate this, and it's likely we would jump over 2010 and move to Visual Studio 2012 at that point (per discussions on python-dev). As for your first point, Visual Studio 2008 is still available on the Microsoft site, it's just not the first thing you usually find. If you look here - http://msdn.microsoft.com/en-us/express/future/bb421473 - you can find it. Anyway, I've done this port internally at my company, but I'm not able to release that patch. I am, however, willing to do it personally so it could be included here. If anyone else is interested in working on it, it should follow the same format as other VS version support, going in the PC/VS{version} folder. Also, reclassified this to the proper version, 3.3, since it's a feature request. |
Here is a quick and dirty draft of the modifications I had to do in order to get Python 2.7.2 to compile with VS2010 on the wiki: http://wiki.python.org/moin/VS2010 I will improve/complete it as I progress. |
The wiki page contains change to distutils, which I believe would not be allowed by the feature freeze. New features (such as support for a new compiler) need to target packaging. |
I think this issue urgently needs a scope defined. What *exactly* is it that you want to achieve? If it's merely being able to compile Python with VS 2010, many of the proposed changes are unnecessary. If you propose that the patch should be used to replace VS 2008 with VS 2010, I suggest that instead of developing it as a patch, you create a hg clone that you maintain on your own. If you propose that Python 3.3 be built and released with VS 2010, then we need to re-evaluate this question again. Wrt. VS 2012, my hope is that this will be available for 3.3 already. If that's not going to happen, I'd be open to switch to 2010 for 3.3 only (and to 2012 for 3.4). |
Martin, what I want to achieve is to ensure that someone can download Python sources and compile them without any modification using a standard install of Windows + Visual Studio 2010 SP1. I don't really care what is the default compiler used to generate the official binaries, this is a decision that should be taken according to what most people use. But a least the compilation should work easily with the recent and popular VS2010 compiler. As I said the patch is for the moment a quick and dirty draft: it breaks compilation with VS2008 and assume VS2010. Of course this is not my goal: the final patch should work with existing compilers as well as VS2010. Which part of the changes do you consider unnecessary? Concerning the target version: I need to use Python 2.7 internally because our application has not been migrated to Python 3. I understand there is a feature freeze on this branch (event though the changes in this case are well localized and not intrusive), so I will target primarily Python trunk for the inclusion of patches, but I will also maintain internally my own set of patches for Python 2.7 (and in the wiki for those who are interested). |
All the parts dealing with packaging, in particular Tools/msi.
Instead of doing so internally, I really suggest to maintain a public |
Packaging makes it easier to distribute Python among my colleagues and customers, so I think it is a nice addition. OK for the hg clone, I will set up that (I actually already use mercurial internally to handle those modifications). |
I mentioned this on another issue, but I created a clone at http://hg.python.org/sandbox/vs2010port/. I've already gone through the port in the past but wasn't able to release the code at the time. As I work through it, I'll occasionally announce large milestones here. |
Thanks. I was going to ask about this to see if anyone had already done |
I don't have commit access on hg.python.org, so I also created a clone on bitbucket at: I work with a patch queue for the moment since everything is not completely settled yet. The patch are against python 2.7 for the moment, I will do the same for python trunk soon. Currently I am at: |
Just to be sure in case you didn't know, but patches against 2.7 for this issue won't be accepted. |
Yes I know, but this is my primary target as this is the version that I use in my product for the moment. I will test python trunk soon now that Python 2.7 with VS2010 is in a rather good shape. |
Just to avoid misunderstandings: The Subversion concept of trunk (or rather py3k trunk) maps to the Mercurial branch named default, which is what you get when you clone hg.python.org/cpython. This is 3.3. |
Before we both go down the same paths and duplicate effort, http://hg.python.org/sandbox/vs2010port/ has already completed the transition in terms of running the conversion, saving off the VS9 files, making some minimal code changes (errno module specifically), and has begun to fix tests. This is already done for 'default' aka 3.3. 8 tests failed: The distutils and packaging test failures seem to be about differences in command line flags for some of the VS2010 binaries (looks like a link.exe issue in one). Most of the others are about remaining errno differences, and the subprocess issue is with too many files being open. |
OK Brian, I checked your clone and I will keep an eye on it. I have done almost the same thing for the moment. My patch queue includes some additional corrections for a few more bugs that prevented me from completely running the test suite (crash dumps). I will start working on Python 'default' probably tomorrow. |
If you want to clone from that repo, use the "vs2010" branch. hg clone http://hg.python.org/sandbox/vs2010port/ From there, you can post patches here that I can integrate for you. |
A tip to make Mercurial download only a subset of all the changesets in the repo: hg clone URI -r branch or hg clone URI#branch (The difference is that in the second form, URI#branch will be recorded in the .hg/hgrc file and subsequent pulls will only pull from that branch.) bandwith-is-a-scarce-resource’ly yours |
I have started working on python default branch. The result is the following so far: Most errors seem related to errno. |
Again, rather than work off of the default branch and duplicate effort, can you work off of the vs2010 branch on http://hg.python.org/sandbox/vs2010port/? |
New changeset 38d7d944370e by Brian Curtin in branch 'default': |
What I just pushed has functioning debug and release builds for both 32 and 64 bit, and the tests introduce no new failures. As noted on python-dev, we may not have build slaves setup for this change yet, so the Windows builds may appear broken. I'll leave this open a bit until the infrastructure has caught up, and until any documentation is completed, which I may open a separate issue for. |
All the old .vcproj files are still there. Probably not useful since the .sln file has been upgraded to VisualStudio 2010. |
New changeset 924c178c0d1d by Brian Curtin in branch 'default': |
Thanks for noticing. I moved them out to PC\VS9.0 rather than outright deleting. |
Here is a patch to the .vcproj files and the .props files, based on my earlier pcbuil10.patch. It also updates the readme, the env.bat, and adds the vs9to10.py file. |
LGTM. Brian? |
+1 on the patch. It fixes a bunch of things that I entered unnecessarily (like explicit .pyd names to fix the warnings), but after staring at the screen for a long time I couldn't figure out what I was doing wrong to need them for some reason. I'm not really interested in supporting VS9 or writing a script for it, but if someone who wanted to use it came up with a script I don't see why we couldn't include it. |
Hm, actually, doing a 64-bit debug build fails with that patch. ctypes, _testbuffer, and xxlimited, the projects I originally had trouble with in the settings, don't link properly. |
Correction, both 64-bit debug and release fail. |
Kristjan, |
I wish people would stop using git-style diffs, then the patch would actually say. However, it applied cleanly to tip at the time it was submitted, so you should be able to go by that. |
Hi, I'll see what went wrong, I admit not trying 64 bit before creating the patch. |
It's an ongoing discussion. Some people favor git diffs because |
That sounds reasonable. So, can't we come up with a diff that does both? The base revision sounds like a completely necessary piece of info. |
I wish MS could come up with a property editor that could show you _only_ the properties that are non-default:
It would make debugging settings _so_ much easier. I'll suggest that to the VS team, all the good that will do. |
I believe there is a bug report against Mercurial to include the base |
This is fun. Some projects have "references" to the pythoncore project. This is a .NET feature and not really useful for normal projects, but it does put an explicit link referrence to the correct .lib file into the linker's input arguments. This is why _testcapi works, and not _testbuffer (try diffing the two .vcxproj files). All of this stems from my patch removing explicit link references to the correct .lib file. Perhaps I can reintroduce that, but in a .props file. |
Ok, I find no way to override the linker so that it does not search the current directory first. |
Sounds good to me. |
Here is an updated patch, with proper project references added and some slight cleanup of .props files. |
After enabling the eol extension and re-checking out my working copy, I've applied the patch successfully, but after I do so, I get this error when trying to open the solution in VS2010: "One or more projects in the solution were not loaded correctly" and C:\Users\jaraco\projects\public\cpython\cpython\PCbuild\pythoncore.vcxproj : error : The imported project "C:\Users\jaraco\projects\public\cpython\cpython\PCbuild\pythoncore_d.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. C:\Users\jaraco\projects\public\cpython\cpython\PCbuild\pythoncore.vcxproj |
Ah, good, it looks as though a file is missing from the patch. I'll fix it. |
PCbuild/build.bat and Modules/_decimal/tests/runall.bat still use vcbuild instead of msbuild. It also seems that if an external dependency is unavailable then msbuild can fail to build targets which do not depend on it. For instance if I rename openssl-1.0.1c to something else, then this causes msbuild to fail without building ctypes. I don't think vcbuild had this problem. |
I propose that we declare this issue closed, and defer any new issues arising from the switch to VS 2010 in separate issues. There will surely be many issues over the next weeks and months, and there is little point in tracking this all on this single page. |
So closing this issue. Kristjan, if you want your patch reviewed further and/or approved by Brian, please copy it into a new issue. |
I agree. There is already an issue regarding the packaging dependencies. It currently references ctypes, but we can rename it to be more broad. |
No broad issues, please. One tracker item, one issue. If something other than _ctypes_test fails to build, it may or may not have the same reason, so caution requires that we assume they are unrelated defects. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: