Sorry for interfering. Any plans for two specific things:
- Binding to custom crate repositories?
- Allowing to release pre-built artifacts for crates?
Thanks
Sorry for interfering. Any plans for two specific things:
Thanks
@gus Thanks for working through all that and giving us the details. Next week the Rust team is meeting in person and we’ll try to regroup to understand the problems you are dealing with, how Cargo can ease them.
It is possible to use other repos than crates.io, though not super tested in the wild. See this unit test, which frobs registry.index in .cargo/config. @alexcrichton says you might also want to look at the implementation of cargo-vendor.
I don’t think there are specific plans for releasing binaries, though it’s known to be a desirable feature.
It'd be helpful to have something that can reproduce some of the issues mentioned -- like Cargo talking to crates.io despite everything being tied to paths. @gus, is the work you've done something you could easily send us in a tarball?
Some updates.
@gus, @alexcrichton, @lucab and I had a quick video call today to discuss Debian’s progress. The notes are available though I guess they will be pretty hard to understand.
Some of the major points:
While I haven’t been doing a lot of coding yet on the bugs to come out of these discussions, I have started a patch to teach cargo to interpret a RUSTFLAGS
environment variable, ala CFLAGS
.
A somewhat tangential point, but I've seen two instances of people who needed to be able to locally mirror the index and packages. I've also personally set up a local mirror of the index because constantly hitting the network (and the occasional outage) are a tremendous pain in the ass.
The major problem is that this makes it impossible to work on public binary packages, because changing the index alters the paths in Cargo.lock
. It would be really nice if whatever is worked out here helps with the above.
I've just realised, for maximum compatibility on 32-bit x86, the stage0 rustc binary could be made into the generic i686 version.
There's been a new stage0 snapshot release (2015-12-18) and the i686 version is unchanged. Have it your way.
Thanks for bringing this up again. If there is a change you are looking for here perhaps you can open an issue to suggest it. I don't recall all the context, and changing the snapshot configuration hasn't been on my radar.
FWIW though, we are planning on removing snapshots completely in favor of using the releases, so any change in snapshots may be short lived.
Ok, thanks for replying. There was never an issue about it so it must have slipped @alexcrichton’s mind.
The idea was to enable the snapshot to be run on pre-P4
hardware too, keeping the default code-generation setting unchanged. Completely transparent but still preserving the option of modifying -C target-cpu=
at build-time.
Hey folks.
I’ve gone through and done a quick summary of the status of each of the issues identified in this thread. The TL;DR is that while several of the issues have been fixed, there’s a lot of work left to do. I have not put much focused effort into these myself.
I think the most notable development is that and @alexcrichton and @wycats agree in principal to adding a new “local registry”, where the packages live on the local filesystem instead of crates.io. This was originally called a “non-goal”, and we expected distros to use path-rewriting to redirect dependencies locally. In @gus’s experience that solution was quite unpleasant, and we want to provide official support for sourcing packages locally.
Issue: https://github.com/rust-lang/rust/issues/29554
Status: Fixed. Thanks @bltaveras
Issue: https://github.com/rust-lang/rust/issues/29555
Status: No progress. @alexcrichton’s build system rewrite though removes snapshots, which is part of the solution. This should be solved sooner than a build system rewrite.
Issue: https://github.com/rust-lang/rust/issues/29556
Status: No progress.
Issue: https://github.com/rust-lang/rust/issues/295577
Status: I’ve put some thought into it, solicited opinions about how to do it, and scrapped a partial patch.
Issue: https://github.com/rust-lang/rust/issues/29558
Status: Fixed. Thanks @DiamondLovesYou
Issue: TODO
Status: Still don’t know the right solution for this. Debian’s default i386 target is older than Rust’s. For now it’s a Debian problem.
Issue: https://github.com/rust-lang/rust/issues/29559
Status: PR open
Issue: https://github.com/rust-lang/rust/issues/29560
Status: No progress.
Issue: https://github.com/rust-lang/rust/issues/29561
Status: Fixed. Thanks @wthrowe
Issue: https://github.com/rust-lang/rust/issues/16402
Status: No progress.
Issue: https://github.com/rust-lang/rust/issues/29562
Status: No progress.
Issue: https://github.com/rust-lang/rust/issues/29563
Status: No progress.
Issue: https://github.com/rust-lang/cargo/issues/2107
Status: No progress.
Issue: https://github.com/rust-lang/cargo/issues/2108
Status: Partially fixed. The Cargo that Rust releases are paired with is tagged with a release number. Still don’t have the automation up to make Cargo release artifacts.
Issue: https://github.com/rust-lang/cargo/issues/2109
Status: No progress.
Issue: TODO
Status: No progress.
Issue: https://github.com/rust-lang/cargo/issues/2110
Status: No progress. I’m having second thoughts about doing this at all though. ISTM that once a distro has a binary version of Cargo they can build future
Issue: https://github.com/rust-lang/cargo/issues/2111
Status: No progress, though there’s a new issue about making Cargo work with local registries instead of crates.io.
Issue: https://github.com/rust-lang/cargo/issues/2112
Status: PR open.
@brson you've got a typo in the issue link, should be Bootstrapping unstable code from a stable compiler · Issue #29557 · rust-lang/rust · GitHub
Unfortunately, i686 (Pentium Pro etc) is still too old for Rust’s default configuration, which wants SSE2 instructions (introduced Pentium 4). I think this was discussed upthread.
In that case, they can either modify a single line before bootstrapping their i686 rustc and make it x87
for everyone, or, and that's what I'd probably do, make just the compiler runtime generic i686 and ship two sets of i686 crates.
Default to the newer one, instruct the user to pass a separately named --target=
in case produced code doesn't run.
Or maybe detect the required version at installation time and download just the right i686 set.
Hey everyone,
I’ve been working on cleaning up and improving the rustc and cargo builds for openSUSE the last few days, and as part of that I ended up working on improving the cargo bootstrap.py
script by @dhuseby. I’ve got a patchset in development here, comments / ideas are more than welcome.
Right now I think I have a rough idea of how we could package crates and rust projects for openSUSE - there’s still a lot of work left to do, but I also thought it might be valuable to share my main inspiration, which is the golang packaging macros for rpm developed for packaging golang modules for openSUSE here.
Here’s a question, though: From 1.10, each rustc version willl be bootstrappable from the previous release (so 1.10 with 1.9, 1.11 with 1.10 presumably, and so on). This is good news, but I’m wondering - are you also committing to ensure that rustc 1.10 is bootstrappable with 1.10? If that’s the case, it simplifies things even more…
@krig The self-bootstrap is #29556. I have a WIP patch for this, which I’ll try to post tonight or tomorrow.
Thanks for the link!
Hi there, anybody working on packaging Rust code for Arch Linux?
Would be nice to see Rust appearing in the More detailed guidelines section of this wki:
https://wiki.archlinux.org/index.php/Creating_packages#More_detailed_guidelines
I’m not experienced enough to write it myself, but I can help testing stuff and helping writing an how-to. Feel free to ping me.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.