[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, 28 Jul 2016 08:28:18 +0000


ng0 <address@hidden> writes:

> 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.
> Thanks!
> 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.  
>> WDYT?
>> [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.
> [0]:
> -- 
> ♥Ⓐ ng0

So I picked up rust.scm again and forgot about this thread, only a
search for rust brought it up again.
As this will be a long task obviously, however we finish it, can we file
a bug on it so it is obvious that work is being done on it and there'll
be no dual work on this?

Recently released version 1.10.0 of rust merged the
"--disable-codegen-tests" I needed back when i worked on it.
♥Ⓐ  ng0
Current Keys:
For non-prism friendly talk find me on

reply via email to

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