| msg50506 - (view) |
Author: Paul Moore (paul.moore) *  |
Date: 2006-06-20 09:17 |
| Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. |
|
|
| msg50507 - (view) |
Author: Peter Schwalm (peterschwalm) |
Date: 2006-06-22 11:39 |
| Logged In: YES user_id=1543425 If I interpret the bug tracker correctly, the 2.5 team is not about to change the "normal" build process for windows, because they refer to a special pcbuild8 directory for building with Visual Studio express. Of course if building python 2.5 with VC8 is possible, this is an improvement. But the problem is: the "normal" build process of a python distribution is also integrated into the setup modules for building extensions (. pyd-Files). And that means: anyone who wants to build a c- language extension, has to - either still have the withdrawn MS compiler - or build a custom version of python 2.5 (with pcbuild 8 ). And what about distributing the .pyd-Files if she/he uses alternative 2? One would have to distribute the custom python version too. My conclusion: it would be very helpful if the windows version of python 2. 5 were build with the vc8 compiler! |
|
|
| msg50508 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2006-06-22 12:01 |
| Logged In: YES user_id=113328 Please note: 1. Prior to the existence of the free Toolkit compiler, there was no supported method for building Python with a free compiler. It's sad (and annoying) that MS withdrew the compiler version just as support was added to Python, but it's just a reversion to the prior situation. 2. Building extensions is a separate issue, which is more related to the compiler used to build the official binaries than to what options exist for building Python for yourself. 3. If you want to build extensions for Python, you can use mingw (gcc) as well as MSVC. This has been supported for a long time now. 4. Mingw does not currently support linking with msvcr80.dll, so if the official Python build moves to VC8, we will lose the option of building extensions with mingw. Therefore, I see no advantage to switching the official builds to VC8, in terms of extension building. You gain VC 2005 Express as an option, but lose mingw. As mingw is a long-established option, you in effect lose because you've gone from a well-tested option to a new, relatively untried one. |
|
|
| msg50509 - (view) |
Author: Rene Dudfield (illume) |
Date: 2006-06-30 06:22 |
| Logged In: YES user_id=2042 -1 for killing mingw compatibility by using VC8. |
|
|
| msg50510 - (view) |
Author: Peter Schwalm (peterschwalm) |
Date: 2006-06-30 10:19 |
| Logged In: YES user_id=1543425 When will mingw move to msvcrt80.dll? |
|
|
| msg50511 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2006-06-30 10:49 |
| Logged In: YES user_id=113328 mingw-runtime 3.10 (released a few days ago) supports msvcr80. Python (distutils) would need a patch to supply the necessary flags when it detects that python.exe is using msvcr80 (that's non-trivial, as you need to know, and hard-code, the MSVC compiler version numbers :-(). As we're in feature-freeze for Python 2.5, this won't happen until 2.6, but I am happy to make a patch for 2.6 to support msvcr80 in distutils (assuming someone lets me know the relevant MSVC build numbers when I need them). By the way, this thread is irrelevant to the actual patch, which is merely a doc patch... |
|
|
| msg50512 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2006-06-30 15:55 |
| Logged In: YES user_id=21627 Thanks for the patch, committed as r47162. |
|
|