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 lkcl
Recipients amaury.forgeotdarc, lkcl, loewis
Date 2009-01-16.13:42:00
SpamBayes Score 0.029779369
Marked as misclassified No
Message-id <1232113322.34.0.939295794043.issue4954@psf.upfronthosting.co.za>
In-reply-to
Content
hi amaury, thanks for responding.

> Is Msys+Mingw32 (running on a regular Windows) an interesting
> configuration to support?

 [wine+]msys+mingw32 is used to _build_ python - not depend on it.
 [wine+]msys+mingw32 _replaces_ the proprietary build toolchain MSVC.

 clarification:

 * in the case of #3871, msys+mingw32 replaces MSVC.
 * in the case of #4954, wine+msys+mingw32 replaces MSVC _and_ windows

 but in either case, you end up with a complete build of python.exe,
 libpython2.5.dll and modules that is perfectly well capable of
 running under both wine _and_ native windows...

 ... WITHOUT requiring, in any way shape or form,
 EITHER msys OR mingw32.

 in other words, it's a big damn deal.

 no more proprietary dependence.

 ... let me put it this way, martin: if i told richard stallman that
 you said that "msys+mingw32 was a minority platform" he'd have
 a fit!! :)


> The build tools are similar to the ones used by cygwin, except that the
> C runtime is msvcrt.

 yeeees.... sort-of - but if you do s/#ifdef __CYGWIN__/#if defined
(__CYGWIN__) || defined(__MINGW32__) it all goes _horribly_ wrong :)

 you actually have to do s/#ifdef _MSC_VER/#if defined(_MSC_VER) ||
defined(__MINGW32__) because _MSC_VER is used alll over the place
 to detect and indicate a win32 build (as separate and distinct
 from a cygwin build).
History
Date User Action Args
2009-01-16 13:42:02lkclsetrecipients: + lkcl, loewis, amaury.forgeotdarc
2009-01-16 13:42:02lkclsetmessageid: <1232113322.34.0.939295794043.issue4954@psf.upfronthosting.co.za>
2009-01-16 13:42:01lkcllinkissue4954 messages
2009-01-16 13:42:00lkclcreate