Ned Deily <n...@python.org> added the comment:
Thanks for the detailed analysis. That does seem like a reasonable explanation: the code in setup.py was not expecting to find anything other than system files under /System. For Apple to put other fs mount points in the /System hierarchy seems ... odd but there it is. At first glance, rather than singling out /Systems/Volumes/Data, changing the inclusion test from /System to /System/Library is probably sufficient. In the most recent SDKs, there is also /System/iOSSupport which is probably never going to come up in Python build contexts but it does point out that making assumptions here about the SDK contents is fragile. So perhaps an even better solution would be for setup.py to dynamically build a filter based on the contents of the SDK in use, i.e. examine the top level of System and usr in the SDK? As a reminder when implementing: /usr/local is a bit tricky. IIRC, recent versions of the compiler chain include /usr/local/include and /usrlocal/bin in the default search paths only in cases where an SDK was not explicitly named, the idea being that you don't want to include references to /usr/local files if you are building something to distribute to the world but it's fine (and necessary) to include /usr/local if you are just building something to run locally on the build system. I believe /Library works the same way. The tool chains from older version of Xcode and/or CLTs may work differently. So any changes we make here should try to do the right thing on the build tools for all supported versions of macOS. ---------- components: +macOS nosy: +ronaldoussoren resolution: works for me -> stage: -> needs patch _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41129> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
