Extensibility

[Diggsey]

Cross compiling

rustup currently only gets you 50% of the way towards cross compiling, but you still need a cross-compiling C toolchain, or at the very least a cross-linker for the target platform.

In the future, we'd like to extend this to make cross compiling as easy as humanly possible. However, there are a lot of potential targets, and it will be a long time before we have good support for a significant number of them baked into rustup, so I think it would be useful to think about making this part of rustup extensible.

The best way to achieve this would probably be to use crates.io: crates which follow a particular naming convention would be installable via rustup (which would itself call out to cargo, but we can be intelligent and make sure we always use a toolchain targeting the configured host platform to compile the crate) and each would provide some set of host/target pairs. (There may be multiple options even for a single host/target pair)

Command line extensibility

These would be custom subcommands, again installable via rustup through cargo, and would work basically the same as cargo subcommands but for rustup. These would be used for more variable features which don't fit into the model above.

[shepmaster]

As an addition to the cross-compiling aspect, I'd love to be able to provide a pre-built libcore (not libstd) for AVR targets. Since AVR is a while off from being supported in all the right places, I wouldn't expect the Rust team to want to support it, but rather have an alternate source.

It would be nice to have some hypothetical rustup extend https://github.com/avr-rust/multirust command that would allow people to download a prebuilt compiler in addition to the libcore. Then also the ability to reuse the C toolchain / linker that @Diggsey mentions.

[aidanhs]

I personally would like to:

• rustup toolchain install https://example.com/my-custom-toolchain.tar.gz (not clear if this is the same as rustup extend in previous comment)
• rustup target add my-alternative-custom-stdlib (to the custom toolchain)

Right now I'm downloading the relevant tars manually, extracting them and using their 'install.sh' scripts to put them somewhere so I can rustup toolchain link them.

[shepmaster]

(not clear if this is the same as rustup extend in previous comment)

My intent was something similar to Homebrews "taps": add another source beyond the normal one. This way, the provider of the alternate toolchains / compilers / standard libraries could release updated versions and multirust update would see them. A single tarball seems like it would be better suited to a do-it-once-and-forget-it workflow.

[aidanhs]

My intent was something similar to Homebrews "taps": add another source beyond the normal one.

Ah interesting. Yes, I actually do want this, I guess I wasn't thinking big enough ;) I think tarballs would still be a useful intermediate step though - extend sounds like it could be tricky, both in rustup.rs coming to a decision on what the process would look like for releasing a custom channel (.asc required? etc) and for custom channel maintainers actually putting together the pieces of the puzzle to make it happen.

[brson]

There seem to be a number of ideas discussed in this thread.

[shepmaster]

@brson indeed! I'd be happy to create a new issue for the stuff I was talking about, but I didn't want to create a bunch of separate issues if there wanted to be one overarching "extensibility" story.

[brson]

@shepmaster I think it would be worth having dedicated threads.