[Pythonmac-SIG] Building extension modules with Xcode 5

[Andrew Barnert]

> From: Kevin Walzer <kw at codebykevin.com>

> Sent: Thursday, October 24, 2013 6:14 PM
>
> On 10/24/13 7:50 PM, Andrew Barnert wrote:

>>  What should users be doing until this is fixed?
> 
> Build Python yourself, in my view. Python is one of the easiest scripting 
> languages to build. And once you do that, building extensions is just a matter 
> of sudo easy_install foo.

Well, as I said, I personally build it myself, either manually or via Homebrew. And I've told novices to "use Homebrew" with a link to brew.sh and they've figured it out themselves. (And that also gives them up-to-date setuptools and pip, and the only problem they ever run into is figuring out that you need to "brew install gfortran" before "pip install numpy scipy", which is not hard to explain.)

But I've gotten resistance from others telling me I shouldn't be telling novices to do that.

And really, if this is the answer, there shouldn't be binary installers on python.org in the first place.

> What we're seeing here is a conflict between Python's unfortunate 

> insistence on using the same compiler toolchain for the main interpreter and any 
> compiled extensions, and Apple's remorseless dropping of stuff it no longer 
> supports.

Also Python having a single binary for 10.6+. I understand that decision—the only alternatives are to tell 10.6 users they're stuck with 2.7.5/3.3.2 forever, or to double the number of builds and double the packagers' work. But Apple consistently and intentionally makes it hard to support more than 3 (sometimes even 2) major OS X versions at a time, and they do a good job of that.

> I don't believe there is a way to resolve this conflict. Eventually clang 
> will have been the standard compiler for three or four versions of OS X, and 
> that will resolve it. Until then there will be several different compilers in 
> the wild--gcc-4.2, gcc-llvm, and clang, and we'll have these headaches with 
> incompatibility.

I think the only reason we're explicitly using gcc 4.2 is because it was required with Xcode 3.0 on OS X 10.5, or something like that. If that workaround is no longer relevant, and is now causing problems, why not just drop it?


And if I'm right, then there is an easy way to resolve this conflict. (The 10.6 SDK thing is less solvable, but also less critical. Most people need to pip install packages; only a few need to redistribute those packages as binaries.)