homepage

The issue is more annoying than the change of location of the SDK, the path to the compiler has also changed unless users manually install the Unix command-line tools, either using a button in the GUI or by installing a separate DMG.
There seem to be two options to thoroughly fixing this:
1) Tell users they must install the unix tools (cltools*.dmg)
 I'm not 100% sure at this time that this would work, from what I've
 learned from inspecting the installer packages this seems to imply
 "-isysroot /" (that is, no /Developer/SDKS/....)
 A small change to distutils and packaging would switch distutils from
 using "-isysroot /Developer/SDKs/..." to "-isysroot /" when it 
 notices that the system root doesn't exist. This is similar to 
 existing hacks for changing a number of compiler flags on OSX 10.3
 when using the 32-bit universal build.
2) Tweak the configure script, distutils and packaging to look for the
 SDK and compiler in the new location if they cannot be found in the
 default location.
 This would be the most user-friendly as the build would "just work",
 but is more work on our end. I have a 10.8 VM with and Xcode install
 where I haven't installed the unix tools to experiment with this. 
 This is definitely more work than running configure with a
 different SDK and custom values for CC and CXX, we also have to 
 convince configure that it isn't performing a cross-build (it seems
 that some compile checks are performed before we add -isysroot to
 CFLAGS and because I don't have the unix tools installed this results
 in a compile failure early in configure)
 This option might be of limited use though: when you want to build
 an extension that uses a C library that isn't shipped with the OS
 (for example PIL with libjpeg) the build of the python extension
 would "just work", but you'd still have to manually specify the
 compiler and system root for the build of libjpeg.