ash-molten icon indicating copy to clipboard operation
ash-molten copied to clipboard

Question about using the external feature in this crate

Open aclysma opened this issue 5 years ago • 0 comments

This is probably a question and not really an issue. Since I had build failures when ash-molten was grabbing and building its own copy of MoltenVK, I decided to try using a prebuilt binary from the Vulkan SDK using the external feature. However it wasn't clear to me what the best way of adding the library to the path would be. I did find a couple solutions that worked, but it took a while to figure it out and I'm wondering if there are better solutions.

Adding a -L via the RUSTFLAGS environment variable works RUSTFLAGS=-L/Users/pmd/dev/sdk/vulkansdk-macos-1.2.131.2/MoltenVK/iOS/static cargo build

Setting LD_LIBRARY_PATH directly actually didn't work for me

I also tried adding this to my build.rs: println!("cargo:rustc-link-search=all=/Users/pmd/dev/sdk/vulkansdk-macos-1.2.131.2/MoltenVK/iOS/static");

However, this didn't work I believe because ash-molten builds first and fails. Since the crate is pretty small, I tried copying/pasting code from this crate into my code and setting up the build.rs like this:

fn main() {
    println!("cargo:rustc-link-lib=framework=Metal");
    println!("cargo:rustc-link-lib=framework=AppKit");
    println!("cargo:rustc-link-lib=framework=QuartzCore");
    println!("cargo:rustc-link-lib=framework=IOKit");
    println!("cargo:rustc-link-lib=framework=IOSurface");
    println!("cargo:rustc-link-lib=dylib=c++");
    println!("cargo:rustc-link-lib=static=MoltenVK");
    println!("cargo:rustc-link-search=all=/Users/pmd/dev/sdk/vulkansdk-macos-1.2.131.2/MoltenVK/iOS/static");
    println!("cargo:rustc-link-lib=static=MoltenVK");
}

It's kind of ugly but ash-molten is small enough that copying/pasting the one lib.rs into my project does seem like a possible solution.

Very long term, I'm kind of thinking I will want to have SDL2 and MoltenVK source vendored so I can easily set breakpoints/add printfs to troubleshoot issues that might arise.. that might be another approach.

Any advice? Right now I lean towards the first method, although I just noticed that it seems to be doing a full build with every code change (including ash, sdl2, etc.)

Sorry for being long-winded, I'm thinking a bit out loud here in case someone has suggestions and for the benefit of anyone else that might try to do this :D

aclysma avatar Jul 18 '20 21:07 aclysma