-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various changes to the build script #28
Conversation
They cause the following warnings: warning: attribute must be of the form `#[link(name = "...", /*opt*/ kind = "dylib|static|...", /*opt*/ cfg = "...")]` --> /tmp/coreaudio-sys/target/x86_64-apple-darwin/debug/build/coreaudio-sys-0d8fd082e359c2ec/out/coreaudio.rs:3:1 | 3 | #[link = "/tmp/MacOSX10.14.sdk/System/Library/Frameworks/AudioToolbox"] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: #[warn(ill_formed_attribute_input)] on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #57571 <rust-lang/rust#57571> And they are actually redundant with the cargo:rustc-link-lib lines the build script prints already.
The last failure here is because this is not my day: https://rust-lang.github.io/rustup-components-history/x86_64-apple-darwin.html says rustfmt is missing just today... |
7588de1
to
add52f5
Compare
The current setup requires 2 environment variables for cross-compilation, and can fail to build under some circumstances on a freshly installed OSX + Xcode machine. This change simplifies the setup by: - On native builds, using `xcrun --show-sdk-path` instead of `xcode-select -p` to find the SDK. - On cross builds, checking COREAUDIO_SDK_PATH. - Pass --target to clang, which makes things work for cross-compilation with plain clang (as opposed to osxcross). - Pass -isysroot to clang instead of -F, which makes it find all possible headers in the SDK, especially TargetConditionals.h, which lives in $COREAUDIO_SDK_PATH/usr/include. - Instruct cargo of the environment variables that affect the build script. COREAUDIO_CFLAGS is left as a convenience, for now.
As of 0.49, bindgen supports a BINDGEN_EXTRA_CLANG_ARGS environment variable that can be used to pass extra arguments to clang. This can be used instead of COREAUDIO_CFLAGS.
Because recent versions of bindgen generate their bindings on one line, because of bindgen's use of u128 and rust's warnings of its unsafety FFI-wise, and because of rust-lang/rust#62999, combined, building the crate generates massive logs... which exceed travis's maximum log length. It was disabled in RustAudio#13 because back then rustfmt had some problems with the bindgen output. Now that rustfmt is part of rust, these kind of problems presumably should happen less if at all.
Simply printing errors to stderr does nothing visible by default. So when building without an SDK available, there is no apparent error showing up other than in some file "hidden" in target/, and an error that including coreaudio.rs failed. Similarly, when attempting to build for an unsupported target, the script reaches the `unreachable!()`.
Instead of passing the full paths to the headers to bindgen, create a meta header that #include's all the needed ones. This leaves it to clang to find them in the right /System/Library/Frameworks directory.
Now that the build script itself doesn't need the SDK path, allow not to specify one explicitly. This allows things to work out when the environment works out of the box one way or another (via wrapper scripts, setting BINDGEN_EXTRA_CLANG_ARGS, etc.)
Just rebased to incorporate the README fixup in the right commit, and to have a green build, now that rustfmt is there for nightly. |
If you want to support |
@seivan would you be up for opening an issue about this? Thanks a lot @glandium, this generally looks good to me! I don't have the ability to test this locally just at the moment - @zicklag would you be interested in reviewing this? It looks like this touches a lot of the cross-compilation support you added recently and looks to simplify things quite a bit with a new bindgen version (most changes are detailed in the commit msgs). |
@mitchmindtree Done: #29 |
@mitchmindtree I can't try it out just yet, but I'll look at it when I next get the chance. It looks like this makes some great improvements! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm testing the new changes now. :)
|
||
```bash | ||
export COREAUDIO_FRAMEWORKS_PATH=/build/osxcross/target/SDK/MacOSX10.11.sdk/System/Library/Frameworks | ||
export COREAUDIO_SDK_PATH=/build/osxcross/target/SDK/MacOSX10.11.sdk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to mention using BINDGEN_EXTRA_CLANG_ARGS
here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It did work for me without having to set any extra clang args, so it might be unnecessary, but in the even that somebody needs it, it could save them some time searching for it.
It worked for my build of Amethyst. 👍 |
Awesome! 🙂 @mitchmindtree Could we make a release for this. I'm using these cross-compiling changes for my project, but I have to use a |
The biggest change is how bindgen is setup both for native and cross compilation. This should finish to address #23.