From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: rust work in progress conflicts Date: Thu, 05 May 2016 15:06:52 +0000 Message-ID: <87eg9gzgqb.fsf@libertad.pw> References: <20160325184540.4e02cb2d@scratchpost.org> <87k2kq6wma.fsf@grrlz.net> <87oa8mt8lh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayKsU-0003qr-7l for guix-devel@gnu.org; Thu, 05 May 2016 11:07:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ayKsI-0005hB-8v for guix-devel@gnu.org; Thu, 05 May 2016 11:07:40 -0400 Received: from hello.itaskmanager.ovh ([2001:41d0:2:1415::1]:42538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayKsI-0005Ug-1M for guix-devel@gnu.org; Thu, 05 May 2016 11:07:34 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by hello.itaskmanager.ovh (Postfix) with ESMTP id 9D491626E1 for ; Thu, 5 May 2016 17:09:19 +0200 (CEST) Received: from hello.itaskmanager.ovh ([127.0.0.1]) by localhost (itaskmanager.ovh [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae3vwC0d7wfG for ; Thu, 5 May 2016 17:09:18 +0200 (CEST) Received: from khazad-dum (x5d83e6dd.dyn.telefonica.de [93.131.230.221]) (Authenticated sender: ng0@libertad.pw) by hello.itaskmanager.ovh (Postfix) with ESMTPSA id 27C86626EC for ; Thu, 5 May 2016 17:09:15 +0200 (CEST) In-Reply-To: <87oa8mt8lh.fsf@gmail.com> (Jelle Licht's message of "Wed, 04 May 2016 12:34:34 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Jelle Licht 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.=20=20 > > WDYT? > > [1]: https://news.ycombinator.com/item?id=3D8732669 > [2]: https://botbot.me/mozilla/rust-internals/2016-04-29/?page=3D3, 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---- --=20 =E2=99=A5=E2=92=B6 ng0