Prompting wasm32-unknown-emscripten users to install Emscripten

[tlively]

Describe the problem you are trying to solve

The wasm32-unknown-emscripten target is unique (AFAIK) in that it requires an external toolchain, Emscripten, to be additionally installed to work correctly. Further, different versions of Rust require different specific versions of Emscripten to be installed and activated to ensure compatibility between the versions of LLVM used by Rust and Emscripten. Unfortunately, the matching Rust and Emscripten versions are not really documented anywhere. While we plan to improve the documentation situation, we will still have the problem of surfacing this issue and its documentation to users who install the wasm32-unknown-emscripten component.

Describe the solution you'd like

I could imagine Rustup helping in multiple ways when wasm32-uknown-emscripten is installed, from simply printing a generic message pointing to documentation, to printing a message identifying the specific version of Emscripten to install, to actually installing the correct version of Emscripten automatically. For now, I would be satisfied if we could just print a generic message. Is that something Rustup would accept a PR for? Would it make sense to pursue doing more than just printing a generic message in the future?

cc @RReverser and @kripken

[kinnison]

This is an interesting idea. The logical extension of this is for channel files to include binary names to search for on the host which if they fail would result in an error message for the user. If on the other hand you need very specific versions of emscripten in order to use that target then perhaps just a message to always display when adding that target might be better.

In theory we could use this to ensure that you're reminded you need the MS linker etc. for windows-msvc targets, or the mingw toolchain for windows-gnu.

I wonder first if this ought to be in the channel files, otherwise it's logic in rustup which would have to be updated should new targets with new requirements be added.

@pietroalbini What thoughts, if any, might you have on this? Do you think it should be a purely rustup-side feature?

[rbtcollins]

Do other distributions of rust also need this capability? If so, we should not centre rustup in the design, though making sure rustup can deliver it is important. In particular going from anything rust -> rustup would probably be a mistake, since rustup isn't guaranteed to be present anywhere today.

As far as rustup impl goes, I very much want to see it data driven rather than static code : we may choose to mirror it with code, but it should be possible to change things on the rust side without requiring a coordinated upgrade of our entire user population, which is what putting the data in the rustup binaries would entail.

[pietroalbini]

I agree that having it in the manifest if feasible would be better!

[tlively]

It looks like the manifests are generated by the build-manifest tool. Would a manifest-based solution involve hard-coding a list of generic external dependencies for each applicable target in that tool or is there a better root source for that information? Right now the Emscripten version is hard-coded in a CI build script and nowhere else. It would be good to avoid having to hard-code it in two locations.

[kinnison]

@tlively I'd expect that it'd be best to ensure theres a single source of truth for the versions, certainly.