[Migrated] External tracking: multiple targets in single cargo process

Issue automatically imported from old repo: https://github.com/EmbarkStudios/rust-gpu/issues/791
Old labels: t: tracking issue,t: external
Originally creatd by khyperia on 2021-11-03T11:10:13Z

For a while, we've been talking about trying to take our absolutely horrifying, fragile, confusing hacks that let users embed rust-gpu programs in host programs and putting them into cargo itself. For example, this discussion (unfortunately in a private section of our discord).

The high-level goal is to basically remove spirv-builder and make its functionality part of cargo itself.

The extremely high level view of how it works, right now, is: "The user writes x86 crate, with a build.rs. There's a build-dependency on spirv-builder, which itself depends on rustc_codegen_spirv. Spirv-builder then invokes a nested cargo process (within the user's build.rs), passing in rustc_codegen_spirv as the backend to use, and using --target spirv-xyz. It then takes the resulting binary and spews it out of the user's build.rs to make it embeddable in the host x86 crate". We've spent countless, countless hours finding an extremely narrow, fragile path that makes it just barely work on most days, but when thursdays roll around, Thor sneezes and an undecipherable error from halfway around the world comes shooting out.

My theory of how this would be integrated into cargo (only a theory, could be implemented in some other way) is to make cargo aware of building multiple targets in a single cargo process invocation. That means that an x86 crate could declare a dependency on a SPIR-V crate (or a wasm crate, too!), and that dependency would get built, binary blob result gathered, and embedded into the host x86 crate. How those dependencies are specified and configured, how it's embedded, how everything works, are very very open questions.

This issue is for the high-level tracking of investigating what design work should be done, and how to go about implementing it - mainly so that this idea doesn't get lost in the depths of chat logs (again). I don't expect detailed design docs to be in this thread or whatever, I mostly intend this as a sticky note of "do this!!" ✨

Key Cargo issues tracking the development of new functionality to support this:

• https://github.com/rust-lang/cargo/issues/9096
• https://github.com/rust-lang/cargo/issues/10030
• https://github.com/rust-lang/cargo/issues/8176 - probably not needed
• https://github.com/rust-lang/cargo/pull/9992
• https://github.com/rust-lang/cargo/pull/10061

Inizia esaminando il flusso attuale di spirv-builder e rustc_codegen_spirv descritto nell’issue, quindi leggi le issue di Cargo collegate 9096 e 10030 e la pull request 10061. Studia come Cargo potrebbe compilare più tipi di target in un singolo processo e documenta le questioni di progettazione relative a dipendenze, configurazione, incorporamento e implementazione. Il lavoro è completato quando sono disponibili una direzione progettuale concreta e un piano di implementazione per sostituire il processo Cargo annidato.