This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lritter
Recipients amaury.forgeotdarc, lkcl, lritter
Date 2009-04-15.15:34:31
SpamBayes Score 3.8857806e-16
Marked as misclassified No
Message-id <1239809675.54.0.837738015507.issue4954@psf.upfronthosting.co.za>
In-reply-to
Content
Hello everyone,

I'm seconding the wish to be able to build Python with MSYS on Win32,
and I can give several technical reasons:

It is my understanding that in order to build an extension for Python on
Win32, one requires to use the same compiler as the one Python has been
built with.

Therefore, the choice of compiler affects not only Win32 developers
working on the interpreter itself, but also developing and porting C/C++
based extensions.

As of now, Microsoft has released its Visual C++ compiler in various
versions, some free of cost (Express), some expensive (Studio). Express
versions change every year, while Studio versions change every two years. 

Express versions supersede each other, so once a new version is
available, the older version is virtually impossible to get.

Python binary releases for Win32 use the Visual Studio 2005 compiler,
which is not freely available, but must be bought. 

Right now, it's impossible to build an extension using distutils without
hacking the VC builder a bit. VCExpress uses a slightly different
registry layout for various settings, which causes the builder to fail.

It takes considerable effort to keep Python/Win32 setup tools compatible
for VC, and all this is done to support the native compiler
sufficiently, a goal that appears to me more and more as an aesthetic
choice rather than a practical one.

A developer wishing to deploy Win32 binaries for his extensions is
currently forced to go through above hurdles or eventually buy a
Microsoft product to make the pain go away.

Cross-building extensions for Python on Unix using Wine is impossible
because no supported version of either VS or VC++ works.

I call this a terrible situation.

Cygwin is the second alternative.

Building Python using Cygwin makes Python and all its extensions
dependent on cygwin.dll, plus it's also, as far as I gather, imitating a
Unix environment for runtimes, rather than a native Win32 one, which may
cripple an applications abilities to adapt to its target platform.

From my perspective, MSYS does deliver. Resulting binaries depend only
on available libraries coming with the OS. MSYS is practically available
to everybody. MSYS also supports cross compiling, so Python binaries
could even be built without Wine. On Windows, Eclipse CDT supports MSYS
as a native backend.

I would actually very much prefer if the default distribution of Python
for Win32 were to use MSYS, but I understand that developers working on
the Win32 platform prefer to use their native tools.

It's also unnecessary, as you can gather from the following:

I mainly develop games and multimedia applications on the Linux
platform, for convenience reasons. Using MSYS, I could easily deploy a
minimal custom-built version of Python with required extensions in one
package, without any dependency on simulated unix enviroments. 

I could cross-build these apps on Linux, and test them for Win32 within
Wine. If they work in Wine, they will definitely work on Windows.

I would need neither a VC/VS nor a Windows license to support it.

I call that a wonderful situation.


<offtopic>LKCL: although you are clearly a mad scientist, please do
continue your work. Do not get frustrated by ignorant responses and keep
calm. You do pioneering, disruptive work, and such work will always be
misunderstood and criticized because it requires a throughout
understanding of future possibilities.</offtopic>

Nevertheless, I see the feature you are trying to implement as trivial
and self-explaining, something that should have been part of Python for
a long time. People like me never took the time to file a ticket or make
a comment though. We are busy bastards, I apologize.
History
Date User Action Args
2009-04-15 15:34:36lrittersetrecipients: + lritter, lkcl, amaury.forgeotdarc
2009-04-15 15:34:35lrittersetmessageid: <1239809675.54.0.837738015507.issue4954@psf.upfronthosting.co.za>
2009-04-15 15:34:34lritterlinkissue4954 messages
2009-04-15 15:34:31lrittercreate