openxr_loader lib path on windows contains version number

[swiftcoder]

I had to edit sys/build.rs to contain the version number in order to link the openxr_loader on Windows:

println!("cargo:rustc-link-lib=static=openxr_loader-1_0");

Unclear if this is a Windows-specific issue, or if it's an issue with the version of the openxr SDK used.

[jdm]

cc @Manishearth

[swiftcoder]

I also had to modify the c++ standard library linking as follows:

    if cfg!(any(target_os = "macos", target_os = "freebsd")) {
        println!("cargo:rustc-link-lib=c++");
    } else if cfg!(target_os = "windows") {
        println!("cargo:rustc-link-lib=dylib=ShLwApi");
    } else {
        println!("cargo:rustc-link-lib=stdc++");
        println!("cargo:rustc-link-lib=stdc++fs");
    }

[Ralith]

Looks like CI isn't testing this anywhere but linux, and due to rust-lang/cargo#5015 cannot easily be made to :(

A hand-tested PR fixing the magic on windows would be very welcome.

[Ralith]

This is definitely not an issue on Linux, and the static feature uses a pinned version of the SDK for reproducibility. The only way to use a different version of the SDK is by enabling only the linked feature and arranging for the actual (static or dynamic) linking to take place yourself.

[swiftcoder]

Yes, I think the problem here is that the pinned OpenXR SDK produces a lib with name that is actually different on Windows (i.e. contains the version # on Windows, but not on linux)

[jdm]

@Ralith For CI you can run with --manifest-path path/to/Cargo.toml and you can pass features successfully.

[Ralith]

I'm working within the framework of https://github.com/crate-ci/azure-pipelines, which seems to make slotting in raw options difficult. Possibly related: crate-ci/azure-pipelines#52

[Ralith]

Fixed by #9