Author lkcl
Recipients BreamoreBoy, LRN, WhiteTiger, amaury.forgeotdarc, davidfraser, eric.araujo, giampaolo.rodola, lkcl, rpetrov, rschoon.old, tarek, zooko
Date 2010-11-13.13:11:28
SpamBayes Score 6.26225e-08
Marked as misclassified No
Message-id <>
> The current patch makes too many changes in core distutils functions;
> it cannot be accepted in this form.  I'm sure that most of the needed
> changes can be made in a subclass of the present Mingw32CCompiler.

 that's what i did when creating the _other_ (yet another)
 mingw32 patch - however _some_ minimal changes to core distutils
 _are_ unfortunately required.  and to and - this is,
 after all, a new platform!  it starts off with
 "sys.platform == 'mingw32'", requiring detection of gcc compiler
 type BUT and os type of win32, and goes from there.

 right now, detection logic is:

 * "if gcc on win32 platform, platform MUST be cygwin"
 * "if msvc compiler, platform MUST be win32"

 both of which are... well... wrong! :)

 so, i found that it was necessary to start in and,
 create a platform-type "mingw32" and _then_ it was easy to do
 a MingW32Compiler etc. with (mostly) additions not modifications
 to distutils, but _necessary_ to add in detection of the type.

 if distutils was designed to do "exec import distutils.compiler.%s as compiler" % sys.platform and go from there then this would be an entirely non-issue: no modifications to distutils would be required, just a completely separate module containing the new compiler...

 ... but distutils isn't designed that way, is it? :)

Date User Action Args
2010-11-13 13:11:30lkclsetrecipients: + lkcl, zooko, amaury.forgeotdarc, davidfraser, giampaolo.rodola, tarek, eric.araujo, rpetrov, rschoon.old, WhiteTiger, BreamoreBoy, LRN
2010-11-13 13:11:30lkclsetmessageid: <>
2010-11-13 13:11:28lkcllinkissue3871 messages
2010-11-13 13:11:28lkclcreate