
<html><head></head><body bgcolor="#FFFFFF"><br><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><span>with older releases (I admit I don't understand the ABI compatibility on OSX).</span><br>

</div></blockquote><div><br></div><div>Well, with OS-X, it's not exactly the C lic in the same way, but there are different SDKs for different OS versions, and you can add to that PPC vs Intel processors and 32 vs 64 bit.</div>

<div><br></div><div>So we have for years had two builds for OS-X, and you can add to that Macports, Homebrew, and what have you.</div><div><br></div><div>And the idea that this isn't an issue for gcc makes no sense-- it's such a big issue for Linux, in fact that <a href="http://python.org">python.org</a> doesn't even try to build binaries for Linux, and pypi has disabled binary wheels for Linux.</div>

<div><br></div><br><blockquote type="cite"><div><span></span><br><span>So adding VS 2010 build files to the 2.7 tree would be fine with me,</span></div></blockquote><div><br></div><div>I think this part is a no brainer.</div>

<div><br></div><div>I also think having a 2.8 out there that is exactly the same as 2.7, except that it was built with a different version of a compiler on one particular platform is a very very bad idea.</div><div><br></div>

<div>So how CAN this be addressed? This is really a distribution issue, and the distutils-sig has been hard at work building the infrastructure to support things like this.</div><div><br></div><div>Right now, if you build binary wheels with the two different "official" OS-X builds, you will get two different names, and pop can find the correct one. (last I checked, pip would happily install the wrong one if you asked it to, though I think that is slated to be fixed)</div>

<div><br></div><div>So if a different build of 2.7 for Windows is put out there, we need to make sure it reports the platform in a way that wheel and pip can make the distinction.</div><div><br></div><div>It might be nice to patch the win_inst too--IIRC it's still not very smart about even 32 vs 64 bit builds.</div>

<div><br></div><div>As for stackless--just to be clear--can you use extensions built with the "regular" python with a stack less binary? If so, I understand the concern. If not, then it seems stackless is a separate ecosystem anyway.</div>

<div><br></div><div>Chris</div><div><br></div></body></html>