Open BlueJayLouche opened 6 years ago
looks like an issue with coreaudio, what system is this on?
Tried on a few. All running 10.13(.4?)
Recently there was an update to the coreaudio-sys
crate (bindings to coreaudio on macos) which fixes the generation of bindings on some older systems, but it seems to have affected builds on newer systems.
There's a very similar issue raised here and the issue seems to be related to Apple changing the location of the framework headers. It looks like the dev who raised that PR was able to fix the issue by running xcode-select --reset
in their terminal which seems to have changed the location of the framework headers to one that the coreaudio-sys
crate can detect at compile time.
cc @Rhuagh perhaps we can pick this "infix" path based on the result of xcode-select -p
? E.g. if the path is within the Xcode.app then we use the current path, but if it is not we fall back to the path that @dan-f used to fix their issue? I haven't looked closely enough yet to see if there is a nicer way, just getting down my thoughts.
The basic issue is that the path is not changed automatically to the new location when upgrading osx. So, basically Apple decided on a new location without patching the upgrade path. We could fix this locally in coreaudio-sys, but it will break again the next time Apple do the same thing. I would probably opt for documenting this instead and making sure users are updating their paths when upgrading osx.