Ned Deily <n...@acm.org> added the comment: Éric: I've replied to your review comments in Rietveld. Thanks.
Ronald: "distutils would not only have to check for gcc-4.2 vs. clang, but also needs to strip "-arch ppc" from the compiler flags when it is present and it cannot use gcc-4.2. Otherwise you cannot build extensions for the 32-bit python installer on OSX 10.7 with Xcode 4.2." The 32-bit-only installers uses gcc-4.0, not -4.2 and it uses the 10.4u SDK, neither of which is available with Xcode 4.*. The patch does not currently attempt to support building extensions for the 32-bit-only installers. Besides stripping arch ppc, it would also have to substitute an available SDK (10.6 is the oldest SDK shipping with Xcode 4.2). CFLAGS and LDFLAGS would also have to be edited to remove ppc and the use of 10.3 as a deployment target results in warning messages: #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid even though for simple cases it seems to work. But I think trying to automatically support the 32-bit-only configuration is too intrusive and unnecessary for most users. There are disadvantages to trying to use the old 32-bit-only configuration on newer systems, such as using the older, more broken, or less feature-rich system APIs. One reasonable use case I can think of is for app developers who want to distribute Python-based apps on OS X that run on a range of systems, say 10.4 to 10.7. For those presumably more sophisticated users, documenting the unsupported environment variable settings to override when attempting to build with Xcode 4 should be sufficient. (The safer options of building with Xcode 3 on 10.6 (or earlier) or building their own custom Pythons remain, of course.) "W.r.t. the patch: is it really necessary to use a subshell to look for the compiler? I'd either walk os.environ['PATH'] myself or use xcodebuild to locate binaries." I suppose that could be done. I've tried to minimize the performance impact by only performing the check the first time it is needed and caching the result so it's only done once per Python invocation. I'm concerned about the added complexity of getting the PATH parsing and semantics right; I don't know of any Python code in the standard library that does this. My immediate concern is for the imminent code cutoffs for Python 3.2.3 and 2.7.3 so I've committed the patch, updated for other review comments, for them. I'm deferring looking at doing a PATH walk for the 3.3 version of the code which is needed along with corresponding changes to packaging. There also should be some OS X installer README and/or other documentation of this and other 10.7 and 10.6 issues. I'm considering how to handle that. ---------- priority: release blocker -> deferred blocker stage: patch review -> needs patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
