Strawman: Why not keep multirust separate, and let the community maintain it on its own, so that the core team can concentrate on more core stuff? The sooner more core concerns are resolved, the sooner people can start updating rustc and cargo less frequently (e.g. every six months like clang, or even less frequently).
As an end-user of these tools, the presented plan doesn't seem very appealing to me. FWIW, I don't use multirust at all, even though I guess I am the target market for these things, since i build/test against every channel on multiple operating systems. I don't have any difficulty with the current state of affairs w.r.t. installation, except that the Windows MSIs are not signed, and that there's no standardized C compiler or assembler. Since installation is a non-issue for me, I'd rather see other parts of the toolchain improve besides the installer. I have ZERO problems installing and updating Visual Studio and it doesn't offer any of the automation that multirust does.
Regarding the NDK stuff, I think it is worth considering whether to just standardize on LLVM/clang and its multi-targetting support for everything, and forget everything else (MSVC, GCC). This seems a lot simpler because it would seem to make it possible to bundle everything up easier: "just" compile the C and Rust libs for every target and package them, and ship with the entire LLVM toolchain, including clang and llvm-mc in particular.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.