Re: Rust

[Ludovic Courtès]

Alex Griffin <address@hidden> skribis:

> On Fri, Jul 29, 2016, at 10:16 AM, Ludovic Courtès wrote:
>> Do you know what’s Rust’s bootstrapping story is?  Can we reasonably
>> expect to bootstrap it from source, using a series of previous Rust
>> versions, or using an alternative implementation?
>
> Yes, Rust 1.10 builds with the previous stable release (1.9) for the
> first time. So we will only need one binary to bootstrap Rust. Although
> this will quickly require a long chain of builds because Rust releases
> every 6 weeks and 1.11 is only guaranteed to build with 1.10, etc.
>
> So after only two years we may need to compile like 17 different
> releases to get the current version.

Bah.  If that were the only problem, we could regularly cut the
dependency graph by storing a pre-built binary built using Guix,
assuming Rust builds are reproducible.  (Note that each node in the
dependency graph contributes to the ‘guix build -d’ time by less than a
hundred milliseconds, so the chain can be quite long before it’s a
practical problem.)

Jelle Licht <address@hidden> skribis:

> So, to ad to Alex' point, we would also need to expend (one-time) effort to
> find this 'bootstrap-path' from the OCaml-based compiler to a more recent
> rustc.

I suspect this one-time effort would be quite huge.

> To quote kibwen from [1]:
> "We can determine exactly how many builds you'd need by looking at the
> master snapshot file:
> https://github.com/rust-lang/rust/blob/master/src/snapshots....
> <https://github.com/rust-lang/rust/blob/master/src/snapshots.txt>
>
> According to this, there have been 290 snapshots in total. And keep in mind
> that you would also need to rebuild LLVM quite a few times as well during
> this process, as Rust has continually upgraded its custom LLVM fork over
> the years."
>
> Not sure if all this is worth the effort...

It’s discouraging, indeed.

We need to find a reasonable way forward.  What about starting from the
version that Eric submitted (bootstrapped from the opaque binary), and
from there on do the “build with previous version” thing?

When the chain becomes too long, we’ll host new bootstrap binaries
produced with Guix and cut the initial part of the chain.

Thoughts?

Obviously not ideal, but at least we’d have a clearer track record of
our binaries: we’d document the Guix commit needed to reproduce a
specific binary, and anyone could verify it.

Ludo’.