Project no longer builds on macOS

[BlueJayLouche]

   Compiling coreaudio-sys v0.2.1
   Compiling conrod v0.59.1
error: failed to run custom build command for `coreaudio-sys v0.2.1`
process didn't exit successfully: `/Users/acherry/Developer/rust/projects/spatial_audio_server/target/debug/build/coreaudio-sys-8d5d7dfd24b7f7e8/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-link-lib=framework=AudioUnit
cargo:rustc-link-lib=framework=CoreAudio

--- stderr
error: header '/Library/Developer/CommandLineTools/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/CoreAudio.h' does not exist.
thread 'main' panicked at 'unable to generate bindings: ()', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
             at /private/tmp/rust-20180329-48542-1qv8r4/rustc-1.25.0-src/src/libcore/macros.rs:23
  10: <core::result::Result<T, E>>::expect
             at /private/tmp/rust-20180329-48542-1qv8r4/rustc-1.25.0-src/src/libcore/result.rs:809
  11: build_script_build::build
             at ./build.rs:137
  12: build_script_build::main
             at ./build.rs:152
  13: std::rt::lang_start::{{closure}}
             at /private/tmp/rust-20180329-48542-1qv8r4/rustc-1.25.0-src/src/libstd/rt.rs:74
  14: std::panicking::try::do_call
  15: __rust_maybe_catch_panic
  16: std::rt::lang_start_internal
  17: std::rt::lang_start
             at /private/tmp/rust-20180329-48542-1qv8r4/rustc-1.25.0-src/src/libstd/rt.rs:74
  18: build_script_build::main

warning: build failed, waiting for other jobs to finish...
error: build failed

[freesig]

looks like an issue with coreaudio, what system is this on?

[BlueJayLouche]

Tried on a few. All running 10.13(.4?)

[mitchmindtree]

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.

[Rhuagh]

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.