Ned Deily <n...@python.org> added the comment:

I should have specified that the failures I saw were just with the default 
intel-64 arch on the beta.

After thinking about it a bit and reviewing the code, I think the best approach 
is to handle this in _osx_support.py as part of the compiler flags 
customization.  What's been happening over the years is that Apple has been 
deprecating and then removing system header files and system library files on 
running systems and instead forcing the use of an SDK to build with for both. 
That's fine but, to continue to support a range of systems, we should be able 
to handle the various default configurations when the user does not explicitly 
specify a particular SDK to use. The Apple compiler chain does the right thing 
under the covers so that C compilations just work. setip.py's macosx_sdk_root() 
now has initialization code to discover the path to the system header files 
that the compiler is using; it calls the compiler with -v on a dummy program 
and then scans the compiler output for the include paths searched until it 
finds either /usr/include or a path ending in .sdk/usr/include. (It's a bit
  of a hack but a fairly widely-used hack that works with both clang and gcc, 
at least, and for the Apple-supplied compilers, takes into account the dynamic 
specification of SDK via xcrun.)

I think the thing to do is move that sdk path detection into _osx_support and 
then, at the end of other customization steps, if there isn't already a valid 
-isysroot provided by the user (either through ./configure or CFLAGS et al, add 
a -isysroot for the discovered default SDK path (or /) into the appropriate 
customized compiler and linker flags. It would also provide a function to 
return the SDK path for setup.py (the equivalent of the current 
macosx_sdk_root()) and others to use. setup.py and Distutils should then do the 
right things for both header and library file paths on any configuration 
(whether header files are installed or not and whether lib files are installed 
or not, Command Line Tools or Xcode) and, with luck, any other Distutils 
replacements that also use _osx_support will also do the right thing.

I had contemplated removing _osx_support at some point in the future but, now 
with the return of universal files, I'm glad we didn't.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41116>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to