(discussion) Create custom rustc target for Substrate runtime

[tomusdrw]

From convos with @tomaka :

The idea is that we'd create a JSON file named wasm32-substrate.json, containing a copy of the one of wasm32-unknown-unknown (there's a Rust command to print the built-in target definitions on stdout)
And then you do cargo +nightly build -Z build-std=alloc,core --target=wasm32-substrate
And everything should magically work
Then we could do #[cfg(target_os = "substrate")]
We could conditionally-compile code for substrate or non-substrate
Problematic part is that if people did #[cfg(target_os = "unknown")] then it won't work anymore

I don't have opinion on this topic, but would be good to have some discussion here. CC @bkchr @pepyakin

[tomaka]

Small note: there's a bug in Rust/Cargo right now, and you have to pass the RUST_TARGET_PATH environment variable set to the path that contains wasm32-substrate.json, otherwise the definition will not be found when compiling dependencies.

[tomusdrw]

Just realized that afaict a nice consequence would be getting rid of all the std features in all crates and issues with it's propagation (i.e. something pulling in std, cause you forgot default-features = false). Basically we would just feature gate with #[cfg(target_os = "substrate")] instead.

[bkchr]

Hmm, does this works with the rest of the rust ecosystem that is not controlled by us? They don't know about target_os = "substrate" and will probably not accept patches for such stuff.
We still would need to have default-features = false in our Cargo.toml's and AFAIK you can not enable/disable features based on your target.

[tomaka]

Just realized that afaict a nice consequence would be getting rid of all the std features in all crates and issues with it's propagation (i.e. something pulling in std, cause you forgot default-features = false). Basically we would just feature gate with #[cfg(target_os = "substrate")] instead.

It does make sense to do that for code that calls externalities.
You know the externality exists because you're compiling for Substrate. Assuming that it is there because std is disabled is a just guess, and is less clean.

[tomusdrw]

@bkchr wouldn't this work:

[target.'cfg(not(target_os = "substrate"))'.dependencies]
native = { path = "./a" }

[target.'cfg(target_os = "substrate")'.dependencies]
native = { path = "./a", default-features = false }

https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies

Or are features unified between platforms anyway?

[bkchr]

Just realized that afaict a nice consequence would be getting rid of all the std features in all crates and issues with it's propagation (i.e. something pulling in std, cause you forgot default-features = false). Basically we would just feature gate with #[cfg(target_os = "substrate")] instead.

It does make sense to do that for code that calls externalities.
You know the externality exists because you're compiling for Substrate. Assuming that it is there because std is disabled is a just guess, and is less clean.

Good point :)

@tomusdrw IDK :)

[tomaka]

@bkchr wouldn't this work:

I'm pretty sure that should work.

[bkchr]

rust-lang/cargo#6121

[tomusdrw]

Closing, since imho the biggest gain would be if we could avoid std features in our own crates, but it doesn't seem to be possible because of the cargo issue mentioned by Basti.

[tomaka]

Why not leave this open as a long-term goal? It's strictly more correct than what we're doing.

[tomusdrw]

@tomaka feel free to reopen, but I don't see that many benefits nor will to implement this at all (based on the "amount" of discussion here). Given that we have some ideas of issue tracker being a short-term, achievable tasks I feel it would be moved or closed anyway.