Is this change really needed? That code path seems to be only used in the cross-compiling case which we don't really support for macOS. And we already handle SDK paths for macOS builds in another way: see is_macosx_sdk_path().

Hi @ned-deily. Thanks for the review.

That code path seems to be only used in the cross-compiling case which we don't really support for macOS.

Sure, but there are 2 use cases I have in packaging python for conda-forge.

1. Building natively but setting _PYTHON_HOST_PLATFORM. This would make setup.py think it's cross compiling and not look for any files under /usr or /usr/local. This is useful for making sure all the dependencies come from conda-forge.
2. Cross compiling for macos-arm64 from macos-x86_64 as in gh-86642: Allow cross compiling on darwin #23523

This PR is stale because it has been open for 30 days with no activity.

@ronaldoussoren would you be able to take a look at this?

That PR is no longer relevant for "main" as setup.py has been removed there.

Hi @ned-deily. Thanks for the review.

That code path seems to be only used in the cross-compiling case which we don't really support for macOS.

Sure, but there are 2 use cases I have in packaging python for conda-forge.

1. Building natively but setting _PYTHON_HOST_PLATFORM. This would make setup.py think it's cross compiling and not look for any files under /usr or /usr/local. This is useful for making sure all the dependencies come from conda-forge.

This seems to rely on an implementation detail in the build system, and is IMHO not something we should actively support in this way. If this is useful it should be an explicit configure option.

2. Cross compiling for macos-arm64 from macos-x86_64 as in bpo-42476: Allow cross compiling on darwin #23523

setup.py is no more, so I'll close this PR.