Consider build CLI (e.g. `cargo gpu`) mapping `spirv-std` deps to toolchain & backend versions. about rust-gpu HOT 4 OPEN

Look who has cargo-gpu on crates.io...a couple steps ahead of you 😄

from rust-gpu.

See https://doc.rust-lang.org/cargo/reference/manifest.html#the-metadata-table

With [package.metadata.rust-gpu.*] we could configure anything beyond what we can with just dependencies.

And you have to keep in mind that we can't remove the spirv-std dependency being explicit for several reasons (e.g. users wanting to compile common code, or even the entire shader, as a regular dependency of host code, or me wanting to have access to the breadth of Cargo path/git dependency/override specifiers.

from rust-gpu.

Food for thought, though I don't want this to be come like JS where every tool has its own config file, having a GPU.toml or whatever might be a better route.

from rust-gpu.

krnl has krnlc, which includes rustc_codgen_spirv into the binary and at runtime copies it back to the target dir. I found I had to sym link the rust sys root libs as well. So that's a working example of a cli instead of a builder / build script.

It does something similar to what @eddyb describes with spirv-std, krnl has krnl-core which links to spirv-std, and krnlc looks for krnl-core via cargo_metadata, checks that the version is compatible, and copies that dependency into the generated Cargo.toml for the device crate. This ensures that host and device crates have identical krnl-core / krnl-macros versions. Macros are used to generate host / device bindings, so identical versions means that the private interface can be unstable.

One thing that is somewhat awkward is needing to install krnlc with a specific nightly version, so that it isn't as easy to update and it's more cumbersome to mix two different versions. The spirv-builder dependency means krnlc has to have its own workspace.

Considering that rust-gpu requires a specific nightly, I'm not sure it would make sense to have something like krnlc be installable on stable or even just nightly, but it could. So if rust-gpu handled installing the required nightly + components + rustc_codegen_spirv, that makes it easier for other tools like krnlc or naga to use it.

from rust-gpu.