[Migrated] Refactor how rustc_codegen_spirv is compiled

Issue automatically imported from old repo: https://github.com/EmbarkStudios/rust-gpu/issues/911
Old labels: t: enhancement
Originally creatd by watjurk on 2022-08-18T14:51:57Z

Summary

rustc_codegen_spirv is compiled and discovered in a very hacky way. Cargo compiles rustc_codegen_spirv because it is inside spirv-builder's Cargo.toml as a dependency, and then spirv-builder discovers the rustc_codegen_spirv's dylib by this super hacky function: find_rustc_codegen_spirv. I think this should be avoided.

Motivation

When I've tried to build something using spirv-builder this hacky discovery was not working for me.
Also rustc_codegen_spirv is compiled using the same profile as spirv-builder and we end up with rustc_codegen_spirv being build without optimizations (if we are in debug mode). This is a big problem because compiling rustc_codegen_spirv is a one time cost, but while developing one would recompile thier shaders many times.
Proposed solution is much more elegant than current implemention.

Solution

Let's move rustc_codegen_spirv into another trait witch will compile rustc_codegen_spirv and provide path to it's dylib file.
I've crated an example of how this could be implements: https://github.com/watjurk/spirv-builder-alternative, here is a short summary:

All of this happens inside crates/rustc_codegen_spirv:

Cargo.toml:

[package]
name = "rustc_codegen_spirv_compiler"

src/lib.rs:

pub fn dylib_path() -> PathBuf {
// Compile rustc_codegen_spirv using cargo and return path to it's dylib file.
}

src/rustc_codegen_spirv

Folder with the `rustc_codegen_spirv` crate.

Future

In the future this approach could be modified without breaking code that relies on dylib_path function, for example we can serve pre-builed dylib's of rustc_codegen_spirv and dylib_path instead of building rustc_codegen_spirv will download one of the pre-build dylib's depending on user's hardware.

Commencez par crates/spirv-builder/src/lib.rs, en particulier find_rustc_codegen_spirv, puis examinez crates/rustc_codegen_spirv/Cargo.toml, src/lib.rs et son dossier imbriqué src/rustc_codegen_spirv. Comparez l’organisation proposée du compiler-wrapper avec l’exemple lié. C’est terminé lorsque rustc_codegen_spirv est compilé séparément avec des optimisations appropriées et que son chemin de dylib est exposé sans le hack actuel de découverte.