Microsoft Visual C++ Compiler for Python 2.7
Hi all, (This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.) Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves. The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27 This package contains all the tools and headers required to build C extension modules for Python 2.7 32-bit and 64-bit (note that some extension modules require 3rd party dependencies such as OpenSSL or libxml2 that are not included). Other versions of Python built with Visual C++ 2008 are also supported. You can install the package without requiring administrative privileges and, with the latest version of setuptools (when it releases), use tools such as pip, wheel, or a setup.py file to produce binaries on Windows. Unfortunately, this package isn't necessarily going to help with building CPython 2.7 itself, as the build process is complicated and Visual Studio 2008 is practically required. However, as most people aren't building CPython on Windows, this isn't a huge issue. This compiler package should be sufficient for most extension modules. I should also point out that VC9 is no longer supported by Microsoft. This means there won't be any improvements or bug fixes coming, and there's no official support offered. Feel free to contact me directly <steve.dower@microsoft.com> if there are issues with the package. Cheers, Steve
Awesome!
On Sep 26, 2014, at 2:01 PM, Steve Dower <Steve.Dower@microsoft.com> wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27
This package contains all the tools and headers required to build C extension modules for Python 2.7 32-bit and 64-bit (note that some extension modules require 3rd party dependencies such as OpenSSL or libxml2 that are not included). Other versions of Python built with Visual C++ 2008 are also supported.
You can install the package without requiring administrative privileges and, with the latest version of setuptools (when it releases), use tools such as pip, wheel, or a setup.py file to produce binaries on Windows.
Unfortunately, this package isn't necessarily going to help with building CPython 2.7 itself, as the build process is complicated and Visual Studio 2008 is practically required. However, as most people aren't building CPython on Windows, this isn't a huge issue. This compiler package should be sufficient for most extension modules.
I should also point out that VC9 is no longer supported by Microsoft. This means there won't be any improvements or bug fixes coming, and there's no official support offered. Feel free to contact me directly <steve.dower@microsoft.com> if there are issues with the package.
Cheers, Steve
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
On 26/09/2014 19:01, Steve Dower wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27
Wow. I am lost for words. TJG
At long last! Building C extensions on Windows will no longer be a pain in the rear! On Fri, Sep 26, 2014 at 1:01 PM, Steve Dower <Steve.Dower@microsoft.com> wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27
This package contains all the tools and headers required to build C extension modules for Python 2.7 32-bit and 64-bit (note that some extension modules require 3rd party dependencies such as OpenSSL or libxml2 that are not included). Other versions of Python built with Visual C++ 2008 are also supported.
You can install the package without requiring administrative privileges and, with the latest version of setuptools (when it releases), use tools such as pip, wheel, or a setup.py file to produce binaries on Windows.
Unfortunately, this package isn't necessarily going to help with building CPython 2.7 itself, as the build process is complicated and Visual Studio 2008 is practically required. However, as most people aren't building CPython on Windows, this isn't a huge issue. This compiler package should be sufficient for most extension modules.
I should also point out that VC9 is no longer supported by Microsoft. This means there won't be any improvements or bug fixes coming, and there's no official support offered. Feel free to contact me directly < steve.dower@microsoft.com> if there are issues with the package.
Cheers, Steve
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
On 09/26/2014 11:01 AM, Steve Dower wrote:
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
That's gorgeous! //arry/
On 26 September 2014 19:01, Steve Dower <Steve.Dower@microsoft.com> wrote:
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27
That is fantastic news! Paul
On Fri, 26 Sep 2014 18:01:31 +0000 Steve Dower <Steve.Dower@microsoft.com> wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
When you mention "setuptools", do you imply it doesn't work with plain distutils? Regards Antoine.
On 27 September 2014 22:12, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 26 Sep 2014 18:01:31 +0000 Steve Dower <Steve.Dower@microsoft.com> wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
When you mention "setuptools", do you imply it doesn't work with plain distutils?
I'd expect it to have the same problem the SDK compilers currently do: as far as I am aware, distutils simply doesn't recognise them as available compilers. I personally believe we should treat handling both this and the SDK compilers properly as a platform-enablement bug for distutils and ensure they work properly with the currently maintained branches (including 2.7). David Cournapeau offered (on distutils-sig) to tackle that for at least the SDK compilers (the thread was before Steve's announcement of the more readily available VC9 compiler download). Cheers, Nick. P.S. Note that pip always runs setup.py via setuptools, so updating setuptools also deals with the general "pip install" case of building from source. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 27 September 2014 14:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
I personally believe we should treat handling both this and the SDK compilers properly as a platform-enablement bug for distutils and ensure they work properly with the currently maintained branches (including 2.7).
+1
On Sat, 27 Sep 2014 14:10:48 +0100 Paul Moore <p.f.moore@gmail.com> wrote:
On 27 September 2014 14:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
I personally believe we should treat handling both this and the SDK compilers properly as a platform-enablement bug for distutils and ensure they work properly with the currently maintained branches (including 2.7).
+1
+1 as well. Regards Antoine.
The SDK compilers are not easily fixable (I've tried). The installation is basically corrupt as far as the non-x86 compilers are concerned. The package we just put out is exactly the same files as the SDK with those issues fixed. There's no reason to encourage the SDK at all now (which was the point of the whole exercise from my point of view). Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Antoine Pitrou<mailto:solipsis@pitrou.net> Sent: 9/27/2014 8:32 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7 On Sat, 27 Sep 2014 14:10:48 +0100 Paul Moore <p.f.moore@gmail.com> wrote:
On 27 September 2014 14:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
I personally believe we should treat handling both this and the SDK compilers properly as a platform-enablement bug for distutils and ensure they work properly with the currently maintained branches (including 2.7).
+1
+1 as well. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.c...
Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but "update Python" is a big/impossible ask for a lot of people, whereas "update setuptools" is easy and also covers Python 2.6 and <3.3. The compiler installer can't set the keys that distutils looks for without losing the per-user installation, and it may also corrupt actual installs of Visual Studio. A monkey patch via setuptools was the best way to handle this - covers pip and Cython and can be ported to other libraries that care but avoid setuptools. Now that we have a patch, there's very limited value in fixing 2.7.9, IMO. But I'm willing to be convinced - we can always add a version check to the setuptools patch. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Antoine Pitrou<mailto:solipsis@pitrou.net> Sent: 9/27/2014 5:13 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7 On Fri, 26 Sep 2014 18:01:31 +0000 Steve Dower <Steve.Dower@microsoft.com> wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
When you mention "setuptools", do you imply it doesn't work with plain distutils? Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.c...
I just tried out the compiler and built wininst and wheel dists. Thanks! distutils was *almost* fine using it, but for two snags: * I had to set VS90COMNTOOLS * distutils expects vcvarsall.bat in VC, while you have it in the parent dir The first could be set by the installer of your package. But if it is not feasible to do so, setting an envvar is something that developers can surely be expected to do with instruction. The second is a little more inconvenient. Wouldn't it be possible to put the .bat file in the "right" folder, or if it has to be there, put *another* one in "VC"? (That is what I did.) cheers, Georg On 09/27/2014 05:16 PM, Steve Dower wrote:
Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but "update Python" is a big/impossible ask for a lot of people, whereas "update setuptools" is easy and also covers Python 2.6 and <3.3.
The compiler installer can't set the keys that distutils looks for without losing the per-user installation, and it may also corrupt actual installs of Visual Studio. A monkey patch via setuptools was the best way to handle this - covers pip and Cython and can be ported to other libraries that care but avoid setuptools.
Now that we have a patch, there's very limited value in fixing 2.7.9, IMO. But I'm willing to be convinced - we can always add a version check to the setuptools patch.
Cheers, Steve
If you update setuptools to 6.0 or later, it shouldn't have any trouble detecting it. No need to set any environment variables. FWIW, I put my vcvarsall.bat where I did because it's not the original version. All the files in VC and WinSDK after unmodified from their original release. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Georg Brandl<mailto:g.brandl@gmx.net> Sent: 10/5/2014 3:23 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7 I just tried out the compiler and built wininst and wheel dists. Thanks! distutils was *almost* fine using it, but for two snags: * I had to set VS90COMNTOOLS * distutils expects vcvarsall.bat in VC, while you have it in the parent dir The first could be set by the installer of your package. But if it is not feasible to do so, setting an envvar is something that developers can surely be expected to do with instruction. The second is a little more inconvenient. Wouldn't it be possible to put the .bat file in the "right" folder, or if it has to be there, put *another* one in "VC"? (That is what I did.) cheers, Georg On 09/27/2014 05:16 PM, Steve Dower wrote:
Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but "update Python" is a big/impossible ask for a lot of people, whereas "update setuptools" is easy and also covers Python 2.6 and <3.3.
The compiler installer can't set the keys that distutils looks for without losing the per-user installation, and it may also corrupt actual installs of Visual Studio. A monkey patch via setuptools was the best way to handle this - covers pip and Cython and can be ported to other libraries that care but avoid setuptools.
Now that we have a patch, there's very limited value in fixing 2.7.9, IMO. But I'm willing to be convinced - we can always add a version check to the setuptools patch.
Cheers, Steve
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.c...
On 26.09.2014 20:01, Steve Dower wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27
Awesome! :) Thanks a lot, Steve! Is it possible to compile extensions from Python's numerical stack such as NumPy, SciPy and SciKit, too?
It'll help with the numerical stack, but only a little. The devs involved have largely figured it out already and I can't provide a good Fortran compiler or BLAS library, which is what they need. It'll be much more valuable for the small packages that have one vital C extension - currently those are basically unusable without a wheel or a compiler. Many DB and XML packages seem to fall into this category. It also works for Cython, so anything that uses Cython should work with just these compilers. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Christian Heimes<mailto:christian@python.org> Sent: 9/27/2014 7:19 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7 On 26.09.2014 20:01, Steve Dower wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27
Awesome! :) Thanks a lot, Steve! Is it possible to compile extensions from Python's numerical stack such as NumPy, SciPy and SciKit, too? _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.c...
Steve Dower <Steve.Dower@microsoft.com> wrote:
It'll help with the numerical stack, but only a little. The devs involved have largely figured it out already and I can't provide a good Fortran compiler or BLAS library, which is what they need.
We finally have a MinGW based toolchain that can be used. Making sure it was compatible with VC9 is actually worse than most would expect, as there are subtile incompatibilities between vanilla MinGW and VC9, beyond just linking the same C runtime DLL. But it was worked out: https://github.com/numpy/numpy/wiki/Mingw-static-toolchain As for BLAS, the NumPy/SciPy devs have procured a permission from Intel to use MKL in binary wheels. But still there will be official binaries linked with a free BLAS library available. Currently we use ATLAS, but the plan is to use OpenBLAS (successor to GotoBLAS2) when it matures. OpenBLAS is currently the fastest abd most scalable BLAS library available, actually better than MKL, but it is severely underfunded. It is not a good situation for the industry that the only open BLAS library with the performance of MKL is a Chinese student project in HPC. ATLAS is unfortunately far less performant and scalable. Apple and Cray solved the problem on their platforms by building high-performance BLAS and LAPACK libraries into their operating systems (Apple Accelerate Framework and Cray libsci). But AFAIK, Windows does not have a BLAS library from Microsoft. Sturla Molden
Christian Heimes <christian@python.org> wrote:
Is it possible to compile extensions from Python's numerical stack such as NumPy, SciPy and SciKit, too?
The official NumPy installer is currently built with VC9, so probably yes. Other parts of the SciPy stack needs a Fortran compiler as well, so those might be more tricky. Currently the limitation to Fortran 77 is considered lifted, Fortran 90 and later will be allowed, so g77 is no longer an option. In practice you will need Intel ifort or a patched MinGW gfortran. Because of this the SciPy community has been creating a customized MinGW toolchain (including gfortran) for building binary wheels on Windows. It is patched to make sure that e.g. the MinGW runtime does not conflict with the VC9 code in the official Python 2.7 installer and that libgfortran uses the correct C runtime. The stack alignment is also changed to make it VC9 compatible. There was also a customization of the C++ exception handling. In addition to this the MinGW runtime and libgfortran are statically linked, so there are no extra runtime DLLs to install. https://github.com/numpy/numpy/wiki/Mingw-static-toolchain The toolchain also contains a build of OpenBLAS to use as BLAS and LAPACK when building NumPy and the SciPy stack. Intel MKL or ATLAS might be preferred though, due to concerns about the maturity of OpenBLAS. Sturla Molden
On 26 September 2014 19:01, Steve Dower <Steve.Dower@microsoft.com> wrote:
You can install the package without requiring administrative privileges and, with the latest version of setuptools (when it releases), use tools such as pip, wheel, or a setup.py file to produce binaries on Windows.
From the setuptools changelog, it seems that setuptools 6.0+ should cover this. However, I just got the following error:
.\ve-2.7\Scripts\pip.exe wheel blist Downloading/unpacking blist Running setup.py (path:C:\Work\Projects\buildwheel\ve-2.7\build\blist\setup.py) egg_info for package blist
.\ve-2.7\Scripts\pip.exe list
warning: no files found matching 'blist.rst' Building wheels for collected packages: blist Running setup.py bdist_wheel for blist Destination directory: c:\work\projects\buildwheel\wheelhouse Complete output from command C:\Work\Projects\buildwheel\ve-2.7\Scripts\python.exe -c "import setuptools;__file__='C:\\Work\\Projects\\buildwheel\\ve-2.7\\build\\blist\\setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d c:\work\projects\buildwheel\wheelhouse: running bdist_wheel running build running build_py creating build creating build\lib.win-amd64-2.7 creating build\lib.win-amd64-2.7\blist copying blist\_btuple.py -> build\lib.win-amd64-2.7\blist copying blist\_sorteddict.py -> build\lib.win-amd64-2.7\blist copying blist\_sortedlist.py -> build\lib.win-amd64-2.7\blist copying blist\__init__.py -> build\lib.win-amd64-2.7\blist running build_ext building 'blist._blist' extension Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Work\Projects\buildwheel\ve-2.7\build\blist\setup.py", line 52, in <module> long_description=open('README.rst').read() File "C:\Apps\Python27\Lib\distutils\core.py", line 152, in setup dist.run_commands() File "C:\Apps\Python27\Lib\distutils\dist.py", line 953, in run_commands self.run_command(cmd) File "C:\Apps\Python27\Lib\distutils\dist.py", line 972, in run_command cmd_obj.run() File "C:\Work\Projects\buildwheel\ve-2.7\lib\site-packages\wheel\bdist_wheel.py", line 175, in run self.run_command('build') File "C:\Apps\Python27\Lib\distutils\cmd.py", line 326, in run_command self.distribution.run_command(command) File "C:\Apps\Python27\Lib\distutils\dist.py", line 972, in run_command cmd_obj.run() File "C:\Apps\Python27\Lib\distutils\command\build.py", line 127, in run self.run_command(cmd_name) File "C:\Apps\Python27\Lib\distutils\cmd.py", line 326, in run_command self.distribution.run_command(command) File "C:\Apps\Python27\Lib\distutils\dist.py", line 972, in run_command cmd_obj.run() File "C:\Work\Projects\buildwheel\ve-2.7\lib\site-packages\setuptools\command\build_ext.py", line 54, in run _build_ext.run(self) File "C:\Apps\Python27\Lib\distutils\command\build_ext.py", line 337, in run self.build_extensions() File "C:\Apps\Python27\Lib\distutils\command\build_ext.py", line 446, in build_extensions self.build_extension(ext) File "C:\Work\Projects\buildwheel\ve-2.7\lib\site-packages\setuptools\command\build_ext.py", line 187, in build_extension _build_ext.build_extension(self, ext) File "C:\Apps\Python27\Lib\distutils\command\build_ext.py", line 496, in build_extension depends=ext.depends) File "C:\Apps\Python27\Lib\distutils\msvc9compiler.py", line 473, in compile self.initialize() File "C:\Apps\Python27\Lib\distutils\msvc9compiler.py", line 383, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File "C:\Work\Projects\buildwheel\ve-2.7\lib\site-packages\setuptools\msvc9_support.py", line 52, in query_vcvarsall return unpatched['query_vcvarsall'](version, *args, **kwargs) File "C:\Apps\Python27\Lib\distutils\msvc9compiler.py", line 299, in query_vcvarsall raise ValueError(str(list(result.keys()))) ValueError: [u'path', u'include', u'lib'] ---------------------------------------- Failed building wheel for blist Failed to build blist Cleaning up... PS 15:36 [00:02] C:\Work\Projects\buildwheel pip (1.5.6) setuptools (6.0.1) wheel (0.24.0) This looks suspiciously like http://bugs.python.org/issue7511, which is worrying. Is this not something I should have expected setuptools to have patched? Paul
Paul Moore wrote:
File "C:\Apps\Python27\Lib\distutils\msvc9compiler.py", line 299, in query_vcvarsall
raise ValueError(str(list(result.keys())))
ValueError: [u'path', u'include', u'lib']
---------------------------------------- Failed building wheel for blist Failed to build blist Cleaning up...
.\ve-2.7\Scripts\pip.exe list
PS 15:36 [00:02] C:\Work\Projects\buildwheel pip (1.5.6) setuptools (6.0.1) wheel (0.24.0)
This looks suspiciously like http://bugs.python.org/issue7511, which is worrying. Is this not something I should have expected setuptools to have patched?
Always embarrassing to have to admit this, but there is a bug in my code... :( distutils validates that four environment variables are set after the vcvarsall.bat script - PATH, INCLUDE, LIB and LIBPATH. I neglected to set LIBPATH for 64-bit targets (LIBPATH is used by the compiler when compiling with /clr, which probably no Python extension has done ever). If you have a dirty machine like mine, then it's probably already set globally, which can really mess up your testing. I'm putting up an updated installer for the compilers that will set this variable, so if you haven't grabbed a copy yet hold off for the next 12 hours or so. Otherwise, you can set your LIBPATH variable to any valid path (or maybe just any value - the compiler may not even look if /clr is not passed). Sorry, Steve
Paul
+1 Wow. After PTVS, this is the next big thing for Python developer on Windows. Hoping that someday Python will be treated by Microsoft just like .NET Framework: so we can easily shipped our own modules, not with a complete Python interpreter and packages Thanks Steve! On 9/27/2014 1:01 AM, Steve Dower wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
On Fri, Sep 26, 2014 at 8:01 PM, Steve Dower <Steve.Dower@microsoft.com> wrote:
Hi all,
(This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.)
Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves.
The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27
This package contains all the tools and headers required to build C extension modules for Python 2.7 32-bit and 64-bit (note that some extension modules require 3rd party dependencies such as OpenSSL or libxml2 that are not included). Other versions of Python built with Visual C++ 2008 are also supported.
You can install the package without requiring administrative privileges and, with the latest version of setuptools (when it releases), use tools such as pip, wheel, or a setup.py file to produce binaries on Windows.
Unfortunately, this package isn't necessarily going to help with building CPython 2.7 itself, as the build process is complicated and Visual Studio 2008 is practically required. However, as most people aren't building CPython on Windows, this isn't a huge issue. This compiler package should be sufficient for most extension modules.
I should also point out that VC9 is no longer supported by Microsoft. This means there won't be any improvements or bug fixes coming, and there's no official support offered. Feel free to contact me directly < steve.dower@microsoft.com> if there are issues with the package.
Cheers, Steve
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
This is awesome, thanks. I guess Python 2.6 is not supported, isn't it? -- Giampaolo - http://grodola.blogspot.com
participants (13)
-
Antoine Pitrou -
Christian Heimes -
Donald Stufft -
Eko Wibowo -
Georg Brandl -
Giampaolo Rodola' -
Larry Hastings -
Nick Coghlan -
Paul Moore -
Ryan Gonzalez -
Steve Dower -
Sturla Molden -
Tim Golden