[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rust work in progress conflicts

From: ng0
Subject: Re: rust work in progress conflicts
Date: Thu, 05 May 2016 15:06:52 +0000

Jelle Licht <address@hidden> writes:

> I have taken the liberty to try my hand at finishing this, as I figured
> it would be a good way for me to get more familiar with 'the Guix way'
> of packaging things.

Also, could you please use this email address for further CC
things (I tend to avoid them completely if possible), as the is no longer subscribed to the mailinglist afaik.

> Wow, did I misjudge this rabbit hole though. It seems to be the case that
> rust needs the (most recent) snapshotted binary stage-0 compiler as part
> of the build process. This was not the case some years ago[1], but since
> then, some 319 snapshots have been released.
> Now there are two approaches which might make sense to me:
> 1) We package a recent stage-0 binary (thus adding yet another random
> binary to the mix)
> 2) We bootstrap all the way from the original rust compiler, written in
> ocaml. This would then presumably need to be repeated for each snapshot,
> leading to about 319 iterative compiler build. On my kind-of-okay i7,
> compiling a single rust iteration takes about 25 to 40 minutes.

This sounds expensive. Isn't there a chance to speed this up,
some other developer with a small Cluster of CPUs for computing
at hand?

> I tentatively went with option 1, if only because I would like to see
> results this decade still, and ran into several hurdles that became
> quite manageable with help from the good people of #guix and
> #rust-internals. One more issue yet remains: part of the rust
> compilation process actually calls the 'cc linker'. This part does not
> respect make flags, setenv calls or even rust's special configure flag
> for setting cc.
> Option 1 does not seem feasible at this point of time, but there is some
> light at the end of the tunnel: rust is at some point going to follow a
> convention that will allow bootstrapping compilers via 'master from
> beta, beta from stable and stable from previous stable'[2].
> I am currently thinking of a compromise; basically, at this moment go
> for option 1, and once the policy previously described is properly
> implemented by the rust team, start iteratively bootstrapping rust from
> that point in time.
> tldr: If we can get 'cc' in the build environment, we can have a 'dirty'
> bootstrapped rust very soon. If we want to do it properly, it might take
> a lot longer.  
> [1]:
> [2]:, look
> for eddyb

It's good that there seems to be light at the end, though I did
not expect rust to be that challenging when I started with it to
just package panopticon[0] through cargo import which needs to be
written once rust is done.



♥Ⓐ ng0

reply via email to

[Prev in Thread] Current Thread [Next in Thread]