Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request - ability to fetch installation source code (rustc...) #77

Closed
leonardinius opened this issue Jun 19, 2015 · 22 comments
Closed

Comments

@leonardinius
Copy link

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?

@brson
Copy link
Owner

brson commented Jun 23, 2015

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.

@leonardinius leonardinius changed the title Feature request - ability to fetch installation cource code (rustc...) Feature request - ability to fetch installation source code (rustc...) Jun 23, 2015
@leonardinius
Copy link
Author

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.

@brson
Copy link
Owner

brson commented Jun 24, 2015

I'm happy to leave it open as a reminder to implement the feature when possible. Thanks for opening it.

@alexbool
Copy link

CC me

@brson
Copy link
Owner

brson commented Jul 12, 2015

cc @edunham This is blocked on the upstream story for packaging source code.

@Binero
Copy link

Binero commented Jul 12, 2015

I desperately need this as well.

@MarkSwanson
Copy link

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.

@brson brson mentioned this issue Sep 4, 2015
@timcharper
Copy link

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

@rw
Copy link

rw commented Dec 22, 2015

+1

@alexreg
Copy link

alexreg commented Dec 27, 2015

Thanks @timcharper, good workaround. Any chance of official support for this now, @brson?

@brson
Copy link
Owner

brson commented Dec 28, 2015

@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.

@alexreg
Copy link

alexreg commented Dec 28, 2015

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).

@brson
Copy link
Owner

brson commented Dec 28, 2015

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.

@alexreg
Copy link

alexreg commented Dec 28, 2015

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).

@brson
Copy link
Owner

brson commented Dec 28, 2015

The current plan for multirust-rs is to continue only supporting local toolchains, not global. I'm still not convinced of the use cases.

@alexreg
Copy link

alexreg commented Dec 28, 2015

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).

@mcobzarenco
Copy link

+1

@MarkSwanson
Copy link

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.

@mcobzarenco
Copy link

@MarkSwanson +1 :-)

@tiborgats
Copy link

+2 ;-)

@vadixidav
Copy link

+1

1 similar comment
@nwolber
Copy link

nwolber commented May 17, 2016

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests