Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: sturlamolden on 7 Jul 2010 17:59 On 7 Jul, 23:19, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > D Linking the CRT dynamically and providing an optional download and > install of the redistributables if they're not present. This would > best be done with some support from the Python installation machinery. > -> Small nice size for extensions, still same CRT state problems. This was a problem for py2exe'd apps before Python 2.6 (i.e. no public download for Visual C++ 2003 runtime files.) But for Visual C++ 2008 and 2010, the CRTs can be downloaded from Microsoft and need not be shipped with the application. http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=BD512D9E-43C8-4655-81BF-9350143D5867&displaylang=en
From: Jonathan Hartley on 7 Jul 2010 18:35 On Jul 7, 8:22 pm, "Martin v. Loewis" <mar...(a)v.loewis.de> wrote: > > I presume this problem would go away if future versions of Python > > itself were compiled on Windows with something like MinGW gcc. Also, > > this would solve the pain of Python developers attempting to > > redistribute py2exe versions of their programs (i.e. they have to own > > a Visual Studio license to legally be able to redistribute the > > required C runtime) I don't understand enough to know why Visual > > Studio was chosen instead of MinGW. Can anyone shed any light on that > > decision? > > sturlamolden has already given the primary reason: Python, > traditionally, attempts to use and work with the system vendor's > compiler. On Windows, that's MSC. It's typically the one that best knows > about platform details that other compilers might be unaware of. > > In addition, it's also the compiler and IDE that Windows developers (not > just Python core people, but also extension developers and embedders) > prefer to use, as it has quite good IDE support (in particular debugging > and code browsing). > > Perhaps more importantly, none of the other compilers is really an > alternative. GCC in particular cannot build the Win32 extensions, since > it doesn't support the COM and ATL C++ features that they rely on (and > may not support other MSC extensions, either). So the Win32 extensions > must be built with VS, which means Python itself needs to use the same > compiler. > > Likewise important: gcc/mingw is *not* a complete C compiler on Windows. > A complete C compiler would have to include a CRT (on Windows); mingw > doesn't (cygwin does, but I think you weren't proposing that Python be > built for cygwin - you can easily get cygwin Python anyway). Instead, > mingw relies on users having a CRT available to > them - and this will be a Microsoft one. So even if gcc was used, we > would have versioning issues with Microsoft CRTs, plus we would have to > rely on target systems including the right CRT, as we couldn't include > it in the distribution. > > HTH, > Martin I see. Thanks very much to both of you for the info, much appreciated.
From: sturlamolden on 7 Jul 2010 18:55 On 8 Jul, 00:35, Jonathan Hartley <tart...(a)tartley.com> wrote: > I see. Thanks very much to both of you for the info, much appreciated. The problem you referred to for py2exe despaired with Python 2.6. For Python 2.5, there was no public download option for msvcr71.dll and msvcp71.dll. There was also the unsolved SxS issue. Thus a license for Visual Studio 2003 was required to distribute py2exe apps for Python 2.5. That is now history. For py2exe apps using Python 2.6, 2.7 or 3.1, you can just ask your clients to install this: http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en There are similar downloads for Visual C++ 2010 run-time files as well. Python 3.2 will probably be built with Visual Studio 2010.
From: David Cournapeau on 7 Jul 2010 23:42 On Wed, Jul 7, 2010 at 9:10 PM, Martin v. Loewis <martin(a)v.loewis.de> wrote: > > My preferred long-term solution is to reduce the usage of the C library > in CPython as much as reasonable, atleast on Windows. Memory management > could directly use the heap functions (or even more directly > VirtualAlloc); filenos could be OS handles, and so on. There are > probably limitations to what you can achieve, but I think it's worth trying. I saw you already mentioned work toward this a few months (years ?) ago. Is there some kind of roadmap, or could you use some help ? I would really like to solve this issue as much as we possibly can, David
From: Martin v. Löwis on 8 Jul 2010 00:46
> I saw you already mentioned work toward this a few months (years ?) > ago. Is there some kind of roadmap, or could you use some help ? I > would really like to solve this issue as much as we possibly can, Well, Python 3 has already dropped stdio for its own io library, and I do want to get rid of the remaining FILE* usage for 3.2. Any other change needs to be discussed on python-dev first; contributions are welcome. Regards, Martin |