Open Diggsey opened 8 years ago
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.
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.
(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.
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.
There seem to be a number of ideas discussed in this thread.
@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.
@shepmaster I think it would be worth having dedicated threads.
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 ofhost
/target
pairs. (There may be multiple options even for a singlehost
/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.