Re: rust work in progress conflicts

[ng0 <ng0@libertad.pw>]

Jelle Licht <jlicht@fsfe.org> 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
@grrlz.net 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]: https://news.ycombinator.com/item?id=8732669
> [2]: https://botbot.me/mozilla/rust-internals/2016-04-29/?page=3, 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]: https://panopticon.re

>>---snip-snap----

-- 
♥Ⓐ ng0