Re: rust work in progress conflicts

[ng0]

Hi,

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
> @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
>

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: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org