Feature request - ability to fetch installation source code (rustc...)
Closed this issue · 22 comments
Disclaimer: I'm newbie in Rust ecosystem, so I might say something silly or well-known (e.g. other alternatives may exist).
Let me start with appreciation bits. I find multirust to be an excellent bit of software, which also happens to allow me to easily switch between different Rust compiler versions, while experimenting with the stuff.
Still, I find myself struggling with Rustc source code downloads and updates. I'm trying to use racer for Rust code completion in Vim. It requires me to provide it with Rust source code directory to perform code lookups and completion.
So, just and idea - do you see multirust as something what could potentially scratch that itch as well? I'm not sure that the scope of the project is: Is it just helper for CI stuff, or is it also intended to be used on daily basis on developers' local workstations?
What do you think? Any hope?
Yes, installation of source is very desirable, both for analysis and debuging. This initially needs to be solved upstream, probably by producing a rust-installer package for the source. Once its packaged better upstream multirust can integrate it.
Good to know. Sorry for re-introducing the same (existing) issue. Haven't done my homework.
Should I close this issue then. Or,maybe leave it as a reminder.
I'm happy to leave it open as a reminder to implement the feature when possible. Thanks for opening it.
CC me
I desperately need this as well.
I also need to keep vim racer in sync with the binary installed by multirust.
You have to do this if you want racer (and tab completion, goto source, etc.) to work correctly.
workaround:
cd ~/.multirust
curl -O https://gist.githubusercontent.com/timcharper/aec864dafb615e8a9eba/raw/01489d57fd75cbef309b4c56dc29345c6d05c79e/Makefile
make toolchains/1.3.0/src
Review the gist here: https://gist.github.com/timcharper/aec864dafb615e8a9eba
+1
Thanks @timcharper, good workaround. Any chance of official support for this now, @brson?
@alexreg It's still not on my near-term todo list. The way I want it implemented is by modifying the Rust makefiles to produce a new rust-installer package called perhaps rust-source and is uploaded alongside the other installers.
Yeah, that would be a good clean way to implement it I suppose. Would be nice to have a (slightly generalised) version of the hack proposed above in multirust already though.
On 28 Dec 2015, at 17:32, Brian Anderson notifications@github.com wrote:
@alexreg https://github.com/alexreg It's still not on my near-term todo list. The way I want it implemented is by modifying the Rust makefiles to produce a new rust-installer package called perhaps rust-source and is uploaded alongside the other installers.
—
Reply to this email directly or view it on GitHub #77 (comment).
FWIW, I'm not sure how much more effort I'm going to put into multirust beyond getting cross-toolchains working. Next quarter I'm planning to move development to multirust-rs.
I have no idea what cross-toolchains are. Are you planning to implement global installations of toolchains in multirust-rs?
Also, I hope you’ll post on the README when you recommend all users switching to multirust-rs. :)
On 28 Dec 2015, at 17:37, Brian Anderson notifications@github.com wrote:
FWIW, I'm not sure how much more effort I'm going to put into multirust beyond getting cross-toolchains #112 working. Next quarter I'm planning to move development to multirust-rs https://github.com/Diggsey/multirust-rs.
—
Reply to this email directly or view it on GitHub #77 (comment).
The current plan for multirust-rs is to continue only supporting local toolchains, not global. I'm still not convinced of the use cases.
I think quite a few people have spoken out about how useful they are, in that thread. There seems to be a lot of support for them. (Also, if it helps, other equivalents of multirust typically support this.) Preventing duplication of installations and huge wastage of space is the biggest one perhaps.
On 28 Dec 2015, at 17:49, Brian Anderson notifications@github.com wrote:
The current plan for multirust-rs is to continue only supporting local toolchains, not global. I'm still not convinced of the use cases.
—
Reply to this email directly or view it on GitHub #77 (comment).
+1
I don't understand the suggestion to unsubscribe.
I believe solving this issue would be (at least) helpful to folks using racer - or some form of tab completion while developing software in Rust.
I see the "+1" as a positive indicator of support for this feature - and positive feedback is important to help devs prioritize things.
@MarkSwanson +1 :-)
+2 ;-)
+1
+1