[Python-Dev] Status of C compilers for Python on Windows
zachary.ware+pydev at gmail.com
Sun Oct 26 05:31:47 CET 2014
On Sat, Oct 25, 2014 at 7:05 PM, Ray Donnelly <mingw.android at gmail.com> wrote:
> On Sun, Oct 26, 2014 at 12:30 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Sat, 25 Oct 2014 19:24:38 -0400
>> "R. David Murray" <rdmurray at bitdance.com> wrote:
>>> I know I for one do not generally test patches on Windows because I
>>> haven't taken the time to learn how to build CPython on it. Sure, I
>>> could test pure python changes by applying patches to an installed
>>> Python, but that's an ongoing pain and I'd rather learn to build CPython
>>> on Windows and get to use the normal hg tools.
>>> If I could use a more linux-like toolchain to build CPython on windows,
>> Well, I don't know how "linux-like" you want your toolchain, but FTR
>> you should be able to build from the command line by running
>> I doubt the MinGW case can be much simpler :-)
> I beg to differ:
> "Tools\buildbot\build.bat" contains:
> @rem Used by the buildbot "compile" step.
> cmd /c Tools\buildbot\external.bat
> call "%VS100COMNTOOLS%vsvars32.bat"
> cmd /c Tools\buildbot\clean.bat
> msbuild PCbuild\pcbuild.sln /p:Configuration=Debug /p:Platform=Win32
> ^ this involves purchasing and installing MS Visual Studio (I'm not
> sure if the Express Edition can be used).
The Express Edition is fine for 32-bit builds. PCbuild\readme.txt has
full details on which editions are needed for what, and in 3.5 also
has a "quick start guide" (absent from older versions due to a
rewriting of the batch scripts that I did a while back):
1. Install Microsoft Visual C++ 2010 SP1, any edition.
2. Install Subversion, and make sure 'svn.exe' is on your PATH.
3. Install NASM, and make sure 'nasm.exe' is on your PATH.
4. Run "build.bat -e" to build Python in 32-bit Release configuration.
5. (Optional, but recommended) Run the test suite with "rt.bat -q".
And really, you can skip step 5 if you don't want to run the tests;
you can skip step 3 if you don't want/need ssl; and you can skip step
2 if you don't want/need bz2, lzma, sqlite3, ssl, or tkinter.
Skipping steps 2 or 3 will cause a lot of angry red text in your build
output, but I hope to solve that problem eventually.
> Without explanations for what each step is doing (I posted those last
> week), on MSYS2:
> Download and run:
> From the MSYS2 shell:
> pacman -S git base-devel mingw-w64-x86_64-toolchain mingw-w64-i686-toolchain
> git clone https://github.com/Alexpux/MINGW-packages
> cd MINGW-packages/mingw-w64-python3
> makepkg-mingw -sL --nocheck
> (remove --nocheck to run the testsuite. Also you could put this into a
> batch file if you were so inclined.)
> To install the newly built packages, from the MSYS2 shell again:
> pacman -U mingw-w64-*.xz
> To run them, you should add /mingw64/bin or /mingw32/bin to your PATH
> (or launch a new shell via mingw32_shell.bat or mingw64_shell.bat)
> Of course, if you don't want to build it from source you can simply issue:
> pacman -S mingw-w64-python3
> .. all of the above applies equally to mingw-w64-python2.
I'm failing to see where that's simpler :)
For the record, on the issue at hand, I agree that any effort should
go toward making it possible to build extensions without MSVC. Once
that problem has been completely solved, then we can consider (long
and hard) building Python itself with something else. I personally
have not been convinced that there's any good reason to do so, but I'm
not unconvincible :)
More information about the Python-Dev