cart / glsl-to-spirv Goto Github PK

Currently, stdc++ must be linked dynamically for GNU toolchains to build from source:

if target.ends_with("-pc-windows-gnu") {
    println!("cargo:rustc-link-lib=dylib=stdc++");
}

This is solvable by rust-lang/rust#37403 via the use of this unstable feature:

• Add #![feature(static_nobundle)] to both lib.rs and build.rs of glsl-to-spirv-builder
• Modify the link to use static-nobundle:

if target.ends_with("-pc-windows-gnu") {
    println!("cargo:rustc-link-lib=static-nobundle=stdc++");
}

$ cargo +nightly-gnu test --release --target x86_64-pc-windows-gnu
   Compiling bevy-glsl-to-spirv-builder v0.1.0 (C:\Users\GrygrFlzr\Documents\projects\glsl-to-spirv\glsl-to-spirv-builder)
   Compiling bevy-glsl-to-spirv v0.2.2 (C:\Users\GrygrFlzr\Documents\projects\glsl-to-spirv)
    Finished release [optimized] target(s) in 1.77s
     Running target\x86_64-pc-windows-gnu\release\deps\bevy_glsl_to_spirv-aeb5d0f8868f37b0.exe

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running target\x86_64-pc-windows-gnu\release\deps\test-fe3b922dfa91430d.exe

running 1 test
test test1 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s

   Doc-tests bevy-glsl-to-spirv

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Of course, this will not build without nightly, so this issue is blocked until the feature is stabilized.

I just tried publishing the new glsl-to-spirv version, but its blocked on the fact that it now uses a "two crate" structure. We moved the "big" files into a new crate, which doesn't have the increased crate size limit. We have options:

1. Move the big files back into the original crate
2. Ask the crates.io team nicely to also raise the limit on the new crate.
3. Try to make naga work for our needs (either by using the subset of glsl currently supported or moving to wgsl)

Motivation
A statically built binary allows us to run bevy games without the additional installation of runtimes on the user end.

Reproduction steps

1. Clone bevy master
2. Add the following to .cargo/config:

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

3. Attempt to run a bevy example:

cargo run --release --target x86_64-pc-windows-msvc --example shader_custom_material

4. Linker error: LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease'

Details
This linker error no longer occurs if I modify glslang to build x86_64-pc-windows-msvc from source like i686-pc-windows-msvc.

The RUSTFLAGS environment variable is not available at build time. I do not believe cargo has a standard way of telling build.rs whether or not the user is requesting a static or dynamic build, which means we cannot automatically switch to building from source whenever a static build is requested.

This places us in an awkward situation for 64-bit MSVC (and potentially all platforms where it uses the prebuilt libraries), because building from source adds to the compilation time, and not everyone should have to pay for optional static linking support (especially since bevy docs recommends a setup with dynamic linking!).

Issues with Attempted Solution
I can make minimal code changes to conditionally compile glsl-to-spirv when the build-from-source feature flag is enabled:

let bin_dir = match target {
    // conditionally build from source
    "x86_64-pc-windows-msvc" => {
        if cfg!(feature = "build-from-source") {
            build::build_libraries(&target)
        } else {
            cargo_dir.join("build").join(&target)
        }
    }
    // other targets
};

Unfortunately, cargo stable will always attempt to enable the feature. This means instead of build-from-source being an opt-in feature, cargo stable will instead prevent opting out.

Nightly allows us to opt out, as mentioned in #7, by using a flag which is stabilized as resolver version 2, and to be made default in rust edition 2021 (see rust-lang/cargo#9048):

# don't eagerly enable features
cargo +nightly run -Z features=itarget --release --target x86_64-pc-windows-msvc --example shader_custom_material

In which case the user can properly opt-in by requesting the feature directly in their Cargo.toml:

[dependencies]
bevy-glsl-to-spirv-builder = { version = "0.1.0", features = ["build-from-source"] }

Potential Impact on Dynamic Builds (until cargo resolver 2 is stable)
Since building from source occurs in parallel with compilation of other bevy dependencies, measurements must not be isolated to building glsl-to-spirv alone. I use the shader_custom_material as a baseline, and cargo clean before every run. The following was run on a Ryzen 7 3700X CPU.

# dynamic build, using pre-compiled libraries
$ cargo +nightly run -Z features=itarget --release --target x86_64-pc-windows-msvc --example shader_custom_material
   Compiling dependencies...
   Compiling bevy v0.4.0 (C:\Users\GrygrFlzr\Documents\projects\clean-bevy)
    Finished release [optimized] target(s) in 1m 45s
     Running `target\x86_64-pc-windows-msvc\release\examples\shader_custom_material.exe`

# dynamic build, using explicit build-from-source
$ cargo +nightly run -Z features=itarget --release --target x86_64-pc-windows-msvc --example shader_custom_material
   Compiling dependencies...
   Compiling bevy v0.4.0 (C:\Users\GrygrFlzr\Documents\projects\clean-bevy)
    Finished release [optimized] target(s) in 2m 13s
     Running `target\x86_64-pc-windows-msvc\release\examples\shader_custom_material.exe`

This is a 28s addition to what was a 105s build process (up by 26.7%) for first time builds and all subsequent builds post-cargo clean.

Temporary Conclusions
Although this cost is only incurred once for the user as it will reuse the libraries on subsequent runs, the additional compile time may be a significant turn-off for new users who just want to get started, and does not give a good impression. Further more, any uses of cargo clean immediately wipes the slate and requires building from source again, as published crates are not allowed to place libraries outside of OUT_DIR.

Once cargo defaults to using resolver version 2, we can make this an opt-in feature without any drawbacks to dynamic builds by default.

Current Workarounds
You could target i686-pc-windows-msvc when static linking, since that target always has to build anyway, but that comes with all the limitations of a 32-bit application vs a 64-bit application.

GNU toolchains currently require dynamically linking stdc++ (unless someone can figure out how to statically link that), so they are not an alternative to MSVC if you are looking for static builds.

The index for the newline following the #version declaration is only valid for the slice in the range source[version...].

When used in