Hi, ng0 <n...@libertad.pw> writes:
> Jelle Licht <jli...@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 > 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
