Repository navigation
Support Visual Studio 2010 #57419
Description
| BPO | 13210 |
|---|---|
| Nosy | @loewis, @mhammond, @jackjansen, @mdickinson, @jaraco, @kristjanvalur, @tjguk, @tarekziade, @merwok, @briancurtin |
| 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/briancurtin'
closed_at = <Date 2012-05-19.18:47:04.551>
created_at = <Date 2011-10-18.12:55:20.824>
labels = ['type-feature', 'OS-windows', 'build']
title = 'Support Visual Studio 2010'
updated_at = <Date 2012-08-20.14:56:37.049>
user = 'https://bugs.python.org/sable'bugs.python.org fields:
activity = <Date 2012-08-20.14:56:37.049>
actor = 'prlw1'
assignee = 'brian.curtin'
closed = True
closed_date = <Date 2012-05-19.18:47:04.551>
closer = 'loewis'
components = ['Build', 'Windows']
creation = <Date 2011-10-18.12:55:20.824>
creator = 'sable'
dependencies = []
files = ['25003', '25004', '25005', '25379', '25433', '25503', '25583', '25636']
hgrepos = []
issue_num = 13210
keywords = ['patch', 'needs review']
message_count = 83.0
messages = ['145803', '145810', '145812', '145820', '145846', '145890', '145892', '145893', '147893', '147894', '148321', '148322', '148325', '148326', '148331', '148488', '148490', '148493', '148664', '148665', '156146', '156150', '156178', '156322', '156658', '156659', '156663', '157214', '157218', '159373', '159375', '159378', '159379', '159380', '159383', '159385', '159386', '159392', '159400', '159401', '159402', '159412', '159413', '159414', '159420', '159424', '159426', '159448', '159462', '159773', '159782', '160241', '160243', '160246', '160261', '160520', '160521', '160532', '160535', '160536', '160653', '160661', '160667', '160668', '160669', '160942', '160953', '160959', '160960', '160961', '160962', '160963', '160965', '161107', '161108', '161109', '161122', '161123', '161144', '161147', '161148', '161162', '161166']
nosy_count = 16.0
nosy_names = ['loewis', 'mhammond', 'jackjansen', 'mark.dickinson', 'jaraco', 'kristjan.jonsson', 'sable', 'tim.golden', 'tarek', 'eric.araujo', 'brian.curtin', 'santoso.wijaya', 'alexis', 'python-dev', 'sbt', 'prlw1']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'commit review'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue13210'
versions = ['Python 3.3']
Activity
sable commentedon Oct 18, 2011
Python for Windows is currently compiled with Visual Studio 2008.
It is not possible to use Visual Studio 2010.
It would be great to be able to compile Python with Visual Studio 2010:
some people may only have access to this compiler which is more recent
when embedding Python in an application compiled with Visual Studio 2010, you mix 2 C Runtime Libraries (msvcr90.dll and msvcr100.dll) which will generally result in a crash
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.
briancurtin commentedon Oct 18, 2011
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.
sable commentedon Oct 18, 2011
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.
I will also do a 64 bits version.
merwok commentedon Oct 18, 2011
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.
loewis commentedon Oct 18, 2011
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).
sable commentedon Oct 19, 2011
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 think other people may be in the same case.
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).
65 remaining items
kristjanvalur commentedon May 17, 2012
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.
loewis commentedon May 17, 2012
I believe there is a bug report against Mercurial to include the base
revision even in git-style diffs, not sure what the status is. git itself
includes the base revision in its diffs; I believe that Mercurial didn't
dare to use the same syntax since the Mercurial hash wouldn't be a valid
git hash.
kristjanvalur commentedon May 17, 2012
This is fun.
the reason why linking is failing for some projects in x64 mode is:
the SolutionDir (or maybe current dir) is implicitly part of the library search path. Therefore, when looking for python33_d.lib, it will find the one in PCbuild, and look into that, and ignore the one in PCbuidl\amd64.
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.
kristjanvalur commentedon May 19, 2012
Ok, I find no way to override the linker so that it does not search the current directory first.
I think it is best, and probably in the spirit of visual studio, to use the "reference" part of a project to facilitate linking between dependency projects. it is designed to take the hassle out of libraries and search paths. I will add references where they are missing.
loewis commentedon May 19, 2012
Sounds good to me.
kristjanvalur commentedon May 19, 2012
Here is an updated patch, with proper project references added and some slight cleanup of .props files.
jaraco commentedon May 19, 2012
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
kristjanvalur commentedon May 19, 2012
Ah, good, it looks as though a file is missing from the patch. I'll fix it.
sbt commentedon May 19, 2012
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.
loewis commentedon May 19, 2012
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.
loewis commentedon May 19, 2012
So closing this issue. Kristjan, if you want your patch reviewed further and/or approved by Brian, please copy it into a new issue.
jaraco commentedon May 19, 2012
I agree. There is already an issue regarding the packaging dependencies. It currently references ctypes, but we can rename it to be more broad.
bpo-14821
loewis commentedon May 19, 2012
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.